Using git rebase Instead of git merge

Using the "git merge" command is probably the easiest way to integrate changes from one branch into another. However, it's not your only option: "git rebase" offers another, slightly different way of integration.

An Example Scenario

Let's take a simple scenario with the following two branches. Our goal is to integrate "branch-B" into "branch-A":

git rebase Avoids Merge Commits

Before we look at the exact steps that occur during a rebase, let's illustrate the differences between merge and rebase.

Using "git merge", the result of our integration would look like this:

Using "git rebase", the end result looks quite different - especially because no extra merge commit will be created. Rebase results in a "straight-line" commit history:

Neither of these scenarios is "better" or "worse" than the other. It's rather a matter of taste and convention in your team!

git rebase in Slow Motion

There's quite a lot happening behind the curtains when a rebase is performed.

In step 1, Git will prepare the receiving branch, in our case "branch-A": all commits that came after the two branches' common ancestor commit (C1) will be removed - just temporarily, of course! Think of them as being parked, ready to be reapplied later.

Step 2 is very easy: Git now integrates the commits from "branch-B". At the end of this step, both branches look exactly the same.

It's the third, final step that gives "rebase" its name: the parked commits from "branch-A" are now reapplied, on top of the just integrated commits. These commits are literally re-based, their new parent commit now being C4.

Be Careful with git rebase

The rebase command is a wonderful and very powerful tool for integrating changes. Keep in mind, though, that it rewrites your commit history.

Let's revisit our above example to illustrate this: before starting the rebase, C3's parent commit was C1. After the rebase, however, C3 is now based on C4!

A revision's parent commit is crucial information. When a commit is rebased onto a new parent, it will also receive a new commit hash. This effectively makes it a completely new commit!

Trouble begins when you rebase commits that have already been published on a remote server. These commits might already be part of your colleagues' work - and should not change their identities! Therefore, please never rebase published commits!

Using git rebase

Actually executing a rebase is dead simple. Make sure you are on the branch that should receive the changes and then simply type...

$ git rebase branch-B

Learn More

• Check out the chapter Rebase as an Alternative to Merge in our free online book
• More frequently asked questions about Git & version control