Rebasing vs Merging. Which should I choose?
Although the above two ways have the same results. But rebasing and merging have completely different ways of working.
Specifically, when you use the git merge command to merge two branches, it will select the last commit on those two branches and create another commit to merge those two commits. It seems that when you use this method, you will have a pretty confusing history if there are no general rules set for team members.
When using git rebase to merge two branches, you will have a better history, more straight line, and easier to see than git merge. But rebasing literally means destroy, it moves the entire branch you want to merge to the top of the main branch and rewrites the commit history for that branch.
So using git merge seems to be a safer option, but the answer to choose to use git merge or git rebase is still yours and depends on the project.
Remember that you should only use git rebase in your own branch and do not use it with anything that has been pushed to the remote if you don’t want to be hated by everyone in the team. And if you are not familiar with rebasing, it is best to use merging because it is safer.
Merge multiple small commits into one main commit with interactive rebasing
To make the histories tree look better, you have to clean it on your branch before pushing it on the remote.
For example: You are writing the comments feature for the company on the feature/comments branch, in the feature/comments branch, there are many other commits that are created after each time you edit something in this branch and you do not clean again. The feature/comments branch before pushing on the remote will help make the company’s histories tree not only harder to observe but also have redundant, unimportant commits on your branch.
So to prevent this, you will use something called squash using the git rebase command with the -i parameter:
Next, the terminal will display a list of all the commits on your branch in order from top to bottom, the latest commits will be at the bottom and the first commits will be on the top:
As you can see above, you have a lot of commits that fix iss and it should be ignored when pushing the code on the remote by replacing the pickup with squash at the beginning of each commit that needs matching.
You should only keep the first commit and the other commits will be merged with this one.
By now, you have seen the effect when using interactive rebasing yet?
Wish you happy learning. Bye!Keywords: Git