Rebasing and merging are both designed to integrate changes from one branch into another branch but in different ways.
For ex. let’s say we have commits like below, the merge will result as a combination of commits, whereas rebase will add all the changes in feature branch starting from the last commit of the master branch:
When you do rebase a feature branch onto master, you move the base of the feature branch to master branch’s ending point.
Merging takes the contents of the feature branch and integrates it with the master branch. As a result, only the master branch is changed. The feature branch history remains same.
Merging adds a new commit to your history.
Commits will look like :
When to rebase? When to Merge?
If the feature branch you are getting changes from is shared with other developers, rebasing is not recommended, because the rebasing process will create inconsistent repositories. For individuals, rebasing makes a lot of sense.
If you want to see the history completely same as it happened, you should use merge. Merge preserves history whereas rebase rewrites it.
Rebasing is better to streamline a complex history, you are able to change the commit history by interactive rebase. You can remove undesired commits, squash two or more commits into one or edit the commit message.
Rebase will present conflicts one commit at a time whereas merge will present them all at once. It is better and much easier to handle the conflicts but you shouldn’t forget that reverting a rebase is much more difficult than reverting a merge if there are many conflicts. You can find details of a basic rebase process from git — Basic Rebase .
Top comments (1)
This has solved one of the most confusing doubts to me.
Thanks for such a clear and comprehensive explanation!