Git: When to Rebase and when to Merge?

Overview

In Git, Merge and Rebase are two of the main ways to integrate changes from one branch to another branch. In this article, we’ll be looking at some of the best practices of using these two commands.

What is Merge?

Merges takes all the changes in one branch and merges them into another branch in one commit and maintains a commit history. It is very much like taking two threads and tying them up in a knot.

Let’s say you have created a branch from X for the purpose of adding a single feature. When you want to bring those changes back to X, you probably want a merge.

    + --- (C1) --- (C2) --- (C3) --- +

    /                                     \

(c0) --- (c1) --- (c2) --- (c3) --- (c4) -----------------  (c4 + C3) [Merged]

Pros:

  1. Simple to use and understand.
  2. The commits on the source branch remain separate from other branch commits. This separation can be useful in the case of feature branches, where you might want to take a feature and merge it into another branch later.
  3. Existing commits on the source branch are unchanged and remain valid. It doesn’t matter if they have been shared with others.

Cons:

  1. History can become polluted by lots of merge commits.
  2. Visual charts of your repository can have non-informative branch lines.

 

What is Rebase?

Rebase changes the base of one branch on top of another branch. That means, it simply places all your commits on top of base commits. In this process, it rewrites the commit history.

Let’s suppose you started adding some features and then another developer made some unrelated changes. You probably want to pull and then rebase to base your changes from the current version of the repository.

Before Rebase :

                                   + --- (C1) --- (C2) --- (C3)

/

(c0) --- (c1) --- (c2) --- (c3) --- (c4) --- (c5)

 

After Rebase:

(c0) --- (c1) --- (c2) --- (c3) --- (c4) --- (c5) --- (C1) --- (C2) --- (C3)

 

Pros:

  1. Simplifies your history and visual charts.

Cons:

  1. In Git, you may push commits you may want to rebase later (as a backup) but only if it’s to a remote branch that only you use. If anyone else checks out that branch and you later rebase it, it’s going to get very confusing.
  2. Each commit is rebased in order, and a conflict will interrupt the process of rebasing multiple commits. With a conflict, you have to resolve the conflict in order to continue the rebase.

Which one should I use ?

Following factors should be considered when choosing which operation to use :

    1. If you are planning to re-integrate a completed feature branch, use merge.
    2. If you have already pushed the branch you are working on, then you should not rebase but merge instead. For branches that have not been pushed, rebase, test and merge.
    3. If you are working on a shared branch or an open source project along with many other developers outside of your team, don’t rebase. Since rebase destroys the branch and other developers will have inconsistent repositories.
    4. If you think there is a chance you will want to revert some changes then use merge, since reverting a rebase is considerably difficult as compared to reverting a merge.

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

STAY UPDATED!

Do you want to get articles like these in your inbox?

Email *

Interested groups *
Healthtech
Business
Technical articles

Archives