Git Rebase and How It Works

Git rebase and how it works in theory and practice.
No matter if you’re a developer, system administrator, or simply a fan of SSH and command line, InMotion’s Cloud VPS 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:

CM
Christopher Maiorana Content Marketing Writer

Christopher Maiorana joined the InMotion community team in 2015 and regularly dispenses tips and tricks in the Support Center, Community Q&A, and the InMotion Hosting Blog.

More Articles by Christopher

Was this article helpful? Let us know!