Merge or Rebase? That’s the Problem

Actually, git rebase and git merge do the same thing but in different ways. They both integrate git commits from one branch into another, but how each of them achieves the desired result, we will discuss in the scope of this article!

First, let’s dive deep into each of these commands and find the exact strategy which suits best for your workflow.

Git Merge

Git merge takes the content of a source branch and integrates it with a target branch. As a result, only the target branch is changed, and the source branch history remains untouched. In other words, when you merge, your HEAD branch generates a new git commit, maintaining the ancestry of each commit history.

Pros

• Provides simple usage.
• Keeps the original context of the source branch.
• Preserves the commit history and the chronological order.
• Separates the commits of the source branch from another one.

Cons

• Litters up the history by a lot of merge commits, thus making the visual charts of Git repository have rainbow branch lines without useful information.

Git Rebase

Git rebase piles all the changes into a single patch and integrates the patch into the target branch. One of the core differences between merge and rebase is that the latter cleans history. In the process of transferring the work from one branch to another, unwanted parts are removed to maintain a linear project history. The command is handy in the cases when you need the recent updates of the master branch in your feature branch, but the history of the master branch must remain clean.

Rebasing re-writes the changes of one branch into another without creating a new commit.

Pros

• Makes the history readable and linear and clears the complex history.
• Cleans the commits by making them a single commit.

Cons

• Doesn’t work with pull requests as you can’t see what minor changes members of the team made.
• Lowers the feature down to a bunch of commits that can hide the context.

When to Merge and When to Rebase?

You’ve already distinguished the two strategies, now let’s discuss use cases.

Investigation

Before taking a step, a careful investigation is always a good idea. It is important to note that chosen strategy should match your workflow. One workflow strategy can be better for one team, while it can be fatal for another team. Therefore, consider each strategy before choosing one.

Individual vs Team Work

If you work individually, it may be convenient for you to choose rebase instead of merge. If you share the feature branch, you are getting the changes from, with other members, the rebasing process will create inconsistency.

Always take into account that merge preserves the history, whereas rebase rewrites it!

In the cases of feature-based workflow, git merge may be the right choice for your team. It also helps you avoid reverting or resetting anything.

As a result of merge, different features remain isolated and don’t interfere with existing commit histories. If the priority is to keep spotless history, then git rebase is a more appropriate version to avoid irrelevant commits.

Conflicts

Reverting a rebase is much harder than reverting a merge as rebase conflicts are presented one commit at a time, whereas merge conflicts are presented all at once. Git allows previewing what will happen when you merge your branch.

However, don’t mess with rebase! Don’t rebase until you know what you are doing. Incorrect rebase can put you in a crucial situation leading to serious consequences.

Always remember not to rebase on a shared branch.

Also, read How to Rebase Git Branch.

In conclusion, rebasing and merging offer the same result by choosing different methods. Each method is unique in its own way. What can be immensely useful for one case, can be fatal for another. A careful investigation can prevent chaos. Thus, always take into account the current situation and possible obstacles for you and your team. Also, check our Git Snippets and Git Book to read about the commands and see examples!