git merge vs. git rebase
Integrating changes from one branch into another branch is a common operation in git workflow. While commands like git merge and git rebase make this possible, things get complicated fast with multiple feature branches and lengthy commit histories. This article explains the difference between merging and rebasing in git, including explanations and best uses cases for each.
Preface: personal preference plays a role...
Before we jump into appropriate use cases for git merge and git rebase, it's important to understand that the best techniques for merging code changes is largely team specific. While some teams may emphasize a clear commit history for each feature, others may prioritize a clean and linear commit history. There really isn't an absolute right vs wrong with these git workflow techniques, however understanding how they work will help you determine what is best for your particular situation.
What does "git merge" do?
You check out a feature branch from master and start making changes. While working on your feature branch, someone else makes changes to the same master branch you forked from. To incorporate the new changes on master, you run git merge to effectively "merge" your changes with the master branch.
When you run git merge, your feature branch generates a merge commit that gets added to the commit history for your feature branch. This has no effect on the master branch but simply updates your local feature branch with the updated changes from master.
Advantages of merging
The nice thing about git merge is that it's non-destructive. It preserves your commit history and keeps the history graph semantically correct.
What does "git rebase" do?
You check out a feature branch from master and start making changes. While working on your feature branch, someone else makes changes to the same master branch you forked from. If you want to combine the changes without adding commits, you run git rebase. This will undo all the commits you've made on your feature branch and reapply them ON TOP OF the changes made to the master branch.
Advantages of rebasing
The main advantage of rebasing is that you avoid the additional merge commit of a regular git merge. It keeps your commit history clean and linear as your commits are integrated directly with the master branch. Instead of having your separate feature branch with it's additional commits, you now have a single commit history based on the master branch.
Which is right for you?
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.
One caveat with rebasing is that it rewrites history. This can lead to serious issues if you don't rebase correctly, 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.
