Git Merge vs Rebase - How To Choose One

If you are all set to develop a feature branch of a master branch to implement the new feature on which you have been working for ages. But, while you are finishing up your work on the features branch – one of your colleagues is making some changes to the master branch. Now, here you might need to ascertain that you have the most updated master on your feature branch before creating a pull request. And, for that you have two options ahead of you - Git Merge or Git Rebase – on this note dev community divides.

What is a Git Merge?

Source: dzone

The merge is git command to let you adopt all the development changes incurred on the master branch and perfectly integrate them into the feature branch on which you have been working. With the single merge command, you will coil all the latest changes made in the master branch. However, there’s a tiny issue if your master branch is hypoactive, then this could pollute the history of your feature branch. So, if you are opposing to merge commits in your feature branch history, then you might need to take a route of rebasing.

What is Git Rebase?

Source: dzone

Rebase command helps in integrating master branch changes to feature branch by tweaking the commit history in the desire to produce a straight and linear succession of commits. Rebasing smoothly shift the feature branch to start on the tip of the master branch. The outcome of rebasing produces no extra commits and all the changes will be aligned up as feature branch commits are added right on the tip of the new master branch.

Git Merge vs Rebase – Working

The working structure of both the git commands makes it harder for developers to pick the one solution. The basic difference between the work structure of the Git Merge and Rebase is:

Merging

Assume you have developed an empty repo with a text file – “Hello World”. But, later on you realize that you should add “This is a line” as the second commit. However, you aren’t satisfied here and thought of adding even more lines so you developed a new branch. This new branch can be referred to as “More lines”.

Meanwhile you are doing all this, another developer working on the master branch decided that “This is a line” should be replaced with “This is a sentence” and commits this change. Now, to adopt this master branch change to your feature branch, you have to merge master into a feature because the master isn’t an ancestor of the last commit on the branch feature.

Source: Atomic Object

To resolve the issue, Git does have a three-way merge between the tips of the two branches and the last updated versions of those two branches. This three-way merge system develops a new commit to adopt the change.

Rebasing

Let’s take the same example where you have created a feature branch meanwhile another developer has added new commits to the master branch. Now, if you want to update your feature branch from the master without using the merge commit, then you could use rebasing. The rebase Git command will replay all feature branches commits onto the tip of the master branch.

Source: Atomic Object

The commits on feature branch are stored in a temporary file and replayed onto master, you essentially rewrite your Git history with the new commits. Moreover, if you face any troubles while replaying the commits on to the tip of master, then you have the full facility to decide how you want to resolve the new commits.

Merging Pros and Cons

Pros

• It comes with a simpler learning curve.
• The maintenance of the original context of the master branch is possible.
• The commits of the master branch are separate from other feature branch commits. This is reformative for you when you want to merge a feature into another branch later on.
• It preserves your commits' history and maintains a semantic history graph for future references.

Cons

• Lots of merge commits can pollute history when multiple developers are working on the same branch. The semantic history graphs become chaotic and don’t interpret much valuable information.
• Running the debugging process using Git bisect becomes a hassle due to merge commits.
• Git log can become pretty messy if not maintained properly.
• Prone to more conflicts when longer lasting feature branches.

Rebasing Pros and Cons

Pros

• History is simplified, aligned and made easier to read.
• Manipulating a singular strand of history is simpler than a history of numerous individual feature branches topped up with additional commits.
• The neat flow of commit messages makes it a silver lining for developers to track a bug when a new feature was introduced.

Cons

• When features are reduced down to a couple of commits, then it can hide context.
• It doesn’t integrate with the pull requests because you can’t see what minor changes someone made. It is a curse for teamwork.
• Users have to put more work while addressing conflicts. With rebase, you have to keep your feature branch updated you have to resolve the same conflicts again and again.

How to Choose Between – Merge & Rebase

If you are swirling in the whirlpool of the ancient debate – whether to vote for merge or rebase, then you need to think logically after accessing all the relevant information and scenarios.

Source: Medium

Imagine, if you go with merge, then you don’t have to rewrite the Git history. So, whenever you want to refer to an exact replica of your repository without losing any history, then merging has a silver lining for you. On the other hand, hefty piles of Git history might create a chaotic environment to find accurate information.

On contrary, if you embrace the rebase on the public branch, then it can lead to confusion. This methodology might completely change history by developing new commits. That means if you rebase and push the changes to the feature branch, then the remote has a thoroughly different history than master branch history. Thus, when you are working with an entire team, proper communication is the only key to implement rebase properly.

Final Verdict

One is no better then the other, both are good options. Both commands have their own set of limitations and perks so we can’t put end to this extended debate. We can just say that you have to understand the power and limitations of both the Git commands before finding the most suitable one according to your project requirements. In the end, decisions are yours to make.