Introduction
Every version control system offers a core set of functionalities, of which, the ability to create branches and then merge changes into branches are offered by both central and distributed version control systems. The way different systems behave is different and hence, often, while the result will be the merging of changes, the way it accomplished and the resulting history created are different.
Consider the following scenario:
You have created a feature branch from a long-running branch. Someone in the team commits in changes into the parent long-running branch and you have to bring in the changes into the feature child branch that you are using for active development. There are two ways to do that in Git:
1. Merge command
2. Rebase command
Both the commands achieve the same outcome of integrating the changes from parent long-running branch into the feature child branch. Where things differ, is the resulting commit history that gets created due to the usage of the commands.
Merge command
In the aforementioned scenario, if you use the merge command, the resulting commit history will bear a merge commit. Note that the merge command does not alter the history of your feature branch in any way. On the contrary, the merge commit provides a context for the changes bought from the parent branch.
Run the following commands in bash shell to simulate a merge in git to bring in changes from a parent branch to a child branch:
$ mkdir Merge
$ cd Merge
$ git init
$ touch file.txt
$ printf “First instalment of work done in master branch” > file.txt
$ git add .
$ git commit “First commit in master branch”
$ git branch dev
$ git checkout dev
$ printf “\n\nWork done in dev branch” >> file.txt
$ git commit -am “First commit in dev branch”
$ git status
$ git checkout master
$ printf “\n\n\n\nSecond instalment of work done in master branch” >> file.txt
$ git commit -am “Second commit in master branch”
$ git checkout dev
$ git merge master
Resolve conflicts, if any. Perform a git commit which is going to be a merge commit.
$ git log –oneline –graph
The result will be something like shown in the image below:
Figure 1 Log history after a merge. Notice the merge commit made in the end
Rebase command
Rebase command, as the name suggests re-creates the base for the child branch while bringing in the changes from the parent branch. This results in a cleaner, unidirectional history, but the context under which the changes were bought in, gets lost. It appears that the child feature branch always worked with the changes bought from the parent long-running since the beginning of its creation.
Run the following commands in bash shell to simulate a rebase in git to bring in changes from a parent branch to a child branch:
$ mkdir Rebase
$ cd Rebase
$ git init
$ touch file.txt
$ printf “Work done in master branch” > file.txt
$ git add .
$ git commit -m “First commit in master branch”
$ git branch dev
$ git checkout dev
$ printf “\n\nWork done in dev branch” >> file.txt
$ git commit -am “First commit in dev branch”
$ git checkout master
$ printf “\n\n\n\nSecond instalment of work done in master branch” >> file.txt
$ git commit -am “Second commit in master branch”
$ git checkout dev
$ git rebase master
Resolve conflicts, if any. Perform a git add . followed by git rebase –continue
$ git log –oneline –graph
The result will be something like shown in the image below:
Figure 2 Log history after a rebase. Notice the second commit from master inserted as a base commit for dev branch
Conclusion
The net outcome of both the rebase and merge command as seen above is the same i.e. integration of changes from one to another branch, here parent to child branch.
Now, naturally, the question arises as to when to use what.
Merge is a non-destructive operation that preserves the chronological order of commits verbatim. The merge command creates a merge commit which brings in a convergence point into the commit history, thereby, bringing in the context under which the integration of changes occurred. This is essential when you are working on a public project and want every developer to have a shared context.
Rebasing a feature branch with changes bought from the long-running parent branch creates a clean linear history in the feature branch. But this eliminates the context under which the activity of rebasing was done. It is preferred when you are working as part of a small team and, it is relatively easy to collaborate and communicate with all the developers about the changes done to the feature branch.
References
1. https://git-scm.com/book/en/v2
2. https://www.atlassian.com/git/tutorials/merging-vs-rebasing
3. https://medium.com/datadriveninvestor/git-rebase-vs-merge-cc5199edd77c