When working with divergent branches in Git, there are certain
circumstances in which a git merge operation may not be the best
choice. At the very least, merge is not the only game in town when it
comes to integrating other lines of work into a single timeline. In
many situations, it may be most advantageous to do a git rebase
instead. In this article, you’ll learn about the rebase command, how
it works, and when and why you may consider using it.
- Git Rebase Instead of a Merge
- Commit References and Rebasing
- The Final Product
Git Rebase Instead of a Merge
As you may already know, Git allows for the creation of multiple
branches that diverge from a “master” branch. On these divergent
branches, multiple changes, and iterations and commits may be made.
Then those changes can be integrated into the master timeline.
Remember, you can create as many divergent branches as you want and
use any naming convention you want, because all of the various named
branches are merely reference pointers to certain commits.
A git rebase will take your most recent commit on a divergent branch
and place it one commit ahead of the commit referenced on the master
branch. Let’s see how that works below.
Commit References and Rebasing
In the below example, notice that the Greek letters represent commits:
alpha (α), beta (β), and gamma (γ)—in a linear
sequence. The “master” reference is pointing to gamma, the most
recent commit on that branch.
α → β → γ [master]
Let’s imagine a branch called “test” diverts from gamma and continues
with a commit named lambda (λ).
λ → μ → ν [test]
This series of commits then proceeds from lambda to mu (μ) to nu
(ν). The reference marker, [test], is pointing to the most recent
commit, which is ν.
With different branches diverging from the master, the timeline can
start to get messy.
A git rebase allows you to integrate all of these changes, which
were happening in parallel branches, into a single master timeline.
Fist, checkout the [test] branch.
git checkout test
Then rebase [test] onto [master].
git rebase master
Now, your timeline will look like this:
α → β → γ [master] → ν [test]
Notice now that [test] sits one commit ahead of [master], but they are
on the same timeline; they share the same history.
The Final Product
All you need to do now is “fast-forward” [master] to meet [test] on
the timeline. First, you will check out [master].
git checkout master
Followed by a standard merge of the [test] branch:
git merge test
Now we have [master] and [test] referencing the same commit.
α → β → γ → ν [test] [master]
So, for example, if you were to push the master branch to a remote
repository, it looks as though all the work up to the current point
was done in a linear sequence rather than in parallel branches:
α → β → γ → ν
Be sure to check out some other Git-related articles in the Support Center:
- Git fundamentals (complete guide)
- How to create your own git server
- Launch a Gitweb installation with NGINX on Debian