The git rebase command has a reputation for being a command that Git beginners should stay away from. However, Git rebasing can actually make life a lot easier for the development team if it is used properly.
Let’s take a quick look and compare the git rebase command with the related git merge command and identify all of the potential opportunities that are presented to incorporate rebasing into the typical Git workflow.
Overview of Rebase and Merge Git Commands
The first thing you want to remember is that both the git rebase command and the git merge command are used to solve the same problem. Both commands are designed to integrate changes from one branch into another branch. That being said, they just do it in very different ways. These commands are two of many that Git has. It may benefit you to learn about the most popular Git commands as well.
When you start working on a new feature in a dedicated branch, and another team member updates the master branch with new commits, it results in a forked history. Anyone who has used Git as a collaboration tool will be familiar with this.
So now let’s say all the new commits in master are now relevant to the feature you are working on. In order to incorporate these new commits into your feature branch, you have two options: Git rebasing or Git merging.
The Git Merging Option
The easiest way to merge the master branch into the feature branch in Git is to use the git merge command. That will look something like this:
[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git checkout feature
git merge master[/ht_message]
Or if you prefer, you can condense that into one line:
[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git merge feature master[/ht_message]
What this does is create a new “merge commit” in the feature branch that will tie together the history of both branches.
Git merging is a great way to go because it is considered a non-destructive operation. This is because the existing branches are not changed in any way. It also helps you avoid the potential pitfalls that come with rebasing, which we will take a look at below.
That being said, the downside means that the feature branch will have an irrelevant or unrelated merge commit every time you need to incorporate upstream changes.
In other words, if the master is very active, then you can pollute your feature branch’s history quite a bit. While you can lessen the damage using advanced git log options, it can still make it hard for other developers to understand the history of the project. You don’t want to continually have to undo changes in Git.
The Git Rebase Option
Git offers an alternative to the git merge command. You can also rebase the feature branch onto master branch using the following commands:
[ht_message mstyle=”info” title=”” show_icon=”” id=”” class=”” style=”” ]git checkout feature
git rebase master[/ht_message]
What this does is move the entire feature branch to begin on the tip of the master branch, effectively incorporating all of the new commits in master. However, instead of using a merge commit, Git rebasing re-writes the project history by creating brand new commits for each commit in the original branch.
The biggest benefit of Git rebasing is that you will get a much cleaner project history because it will eliminate the unnecessary merge commits required by git merge.
Another benefit of using Git rebasing is the fact that it also results in a perfectly linear project history—you can follow the tip of feature all the way to the beginning of the project without any forks. This does make it a lot easier to navigate around your project the git log, git bisect, and gitk commands.
There are in fact a couple of downsides though to Git rebasing and the pristine commit history that comes with it.
Re-writing project history can be potentially catastrophic for your collaboration workflow. Rebasing also loses the context provided by a merge commit, as you can’t see when upstream changes were incorporated into the feature.
Should You Use Rebase or Merge?
Well, let’s sum this up. If you would prefer a clean, linear history free of unnecessary merge commits, you should go for the for the git rebase option when integrating changes from another branch.
However, if you would like to preserve the entire history of your project and also avoid the risk of re-writing public commits, then you should probably stick with git merge.
Both the option of rebasing in Git and merging in Git are valid and workable options. The choice is really up to you and will depend a lot on project and personal opinion.