Git Merge vs Git Rebase

In Git, there are two principle approaches to integrate changes from one branch into another: the merge and the rebase. Git Merge and Git Rebase serve the same purpose. They are designed to integrate changes from multiple branches into one. Although the final goal is the same, those two methods achieve it in different ways, and it’s helpful to know the difference as you become a better software developer.

What is Git Merge?

Git merge allows you to merge branches from Git. It takes the contents of a source branch and integrates it with a target branch. Merging is a common practice for developers. Whether branches are created for testing, bug fixes, or other reasons, merging commits changes to another branch. In this process, only the target branch is changed. The source branch history remains.

How git merge works?

Git merge will combine multiple sequences of commits into one unified history. In these scenarios, Git merge takes two commit pointers, usually the branch tips, and will find a common base commit between them. Once Git finds a common base commit it will create a new "merge commit" that combines the changes of each queued merge commit sequence.

Merging Pros and Cons

Pros
1. It is that it’s non-destructive. It preserves your commit history and keeps the history graph semantically correct.
2. It preserves chronology of commits and creates explicit merge commits (unless fast-forward).
3. This helps keeping information about the historical existence of a feature branch and groups together all commits part of the feature.

Cons
1. History can become intensely polluted by lots of merge commits because multiple people are working on the same branch.
2. Debugging using git bisect can become much harder due to the merge commits.

What is Git Rebase?

Rebase is another way to integrate changes from one branch to another branch. Rebasing is changing the base of your branch from one commit to another making it appear as if you’d created your branch from a different commit. Rebasing flattens the history because it transfers the completed work from one branch to another. In the process, unwanted history is eliminated.

How git rebase works?

Rebasing is changing the base of your branch from one commit to another making it appear as if you’d created your branch from a different commit. Internally, Git accomplishes this by creating new commits and applying them to the specified base. It’s very important to understand that even though the branch looks the same, it’s composed of entirely new commits.

Rebasing Pros and Cons

Pros
1. The primary reason for rebasing is to maintain a linear project history.
2. It keeps your commit history clean and linear as your commits are integrated directly with the master branch.

Cons
1. Rebasing doesn’t play well with pull requests, because you can’t see what minor changes someone made.
2. Another side effect of rebasing with remote branches is that you need to force push at some point. The biggest problem we’ve seen is that people force push — which is fine — but haven’t set git push.default. This results in updates to all branches having the same name, both locally and remotely, and that is dreadful to deal with.

Which one to use?

So what’s best?
If your team uses a feature based workflow, then using git merge may be the best option for preserving the commit history for any given feature. You won’t have to worry about overriding commits or “changing history”. With git merge, different features remain isolated and don’t interfere with existing commit histories.
If keeping your commit history clean is a priority, then rebasing may be most appropriate. You will avoid unnecessary commits and keep changes more centralized and linear.

Rebasing creates nice linear history without merge commits, but is associated with potential risks. If you rebase incorrectly and unintentionally rewrite the history, it can lead to serious issues, so make sure you know what you are doing!

Conclusion

Merging and rebasing ultimately accomplish the same thing: incorporating code changes from branch A into branch B. While git merge creates merge commits to update a feature branch, git rebase rewrites history to integrate a feature branch on top of another branch. Remember that rebasing results in a cleaner commit history while merging simply updates a feature branch with changes made elsewhere.