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.

Handling conflicts in Git with rebasing or merging - Ảnh 1

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.

Handling conflicts in Git with rebasing or merging - Ảnh 2

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:

$ git rebase -i master

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:

pick 380d5e1 release comments feature
squash 30803a6 fix iss1
squash 30803a2 fix iss2
squash 30803a5 fix iss3
squash 30803a3 fix iss4

# Rebase c8d5f6a..30803a6 onto c8d5f6a (2 commands)
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label

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