Rebase is nothing but the process of “unplugging” the branch you want to rebase, and “re-plugging” it on the tip of another branch. But on the other hand, merging takes the contents of the feature branch and then integrates it with the master branch. In this process only the master branch gets changed, whereas the history of feature branch remains the same.
There are a few things you need to consider before you choose an operation between merge and rebase.
A. Is the branch you are getting changes from public? In other words, is the branch shared with other developers outside your team?
If your branch is public, rebase is not recommended. Why? Well, rebase destroys the branch and those developers will have broken or inconsistent repositories unless they use git pull --rebase.
B. Is your developer team experienced enough?
Since rebase is a destructive operation, i.e. if not applied correctly, committed work could get lost, breakage of the consistency of other developer's repositories might occur.
C. You might want to revert the merge for some reason.
Since, reverting a rebase is considerably difficult compared to reverting a merge. Use merge, if you think there is a chance you will want to revert it back.
But let us say, you're working on some development and then another developer made an unrelated change. In this scenario, you probably want to pull and then rebase to base your changes from the current version from the repository. 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.
Merge and rebase will handle conflicts differently. Rebase will present conflicts one commit at a time where merge will present them all at once.
Back