No matter if you're a developer, system administrator, or simply a fan of SSH and command line, InMotion's Cloud Hosting plans provide a fast, scalable environment that is budget-friendly.
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
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:
