Git Rebase: An Illustrated Guide

Feb 13, 2017 | Using Git

Use git rebase to ensure you have the latest code from master, which will help avoid future merge conflicts.

Let’s walk through an example of how git rebase affects commit history:

Imagine you create a feature branch from master, and work on it over the course of a week. On Monday, you complete a  git pull  on master and create a new branch feature_3,   git checkout -b feature_3 .

On Tuesday and Wednesday, you check in three commits (c1, c2, c3), and your git history looks something like this:

this is what your git history looks like to begin

After your last commit on feature_3 you notice a pull request merged into master, that make changes to the classes you’ve been working on in feature_3.

To avoid future merge conflicts you decide to rebase your feature branch. After the rebase, your git history will look something like this:

after rebase, your git history will look like this

example 2, prior commits

You now have the most recent changes from master in your feature_3 branch. Notice how the original commit date from earlier in the week is still intact and you have the most recent commit from master.

What is the command to rebase?

The command  git rebase  will give you:

 First, rewinding head to replay your work on top of it...
Fast-forwarded feature_3 to refs/remotes/origin/feature_3.

if there are no merge conflicts.  

The most recent commits from master are now on your feature branch and you can continue coding.

What if there are merge conflicts during rebase?

The command for our example would be git rebase -i HEAD~3, where -i is “interactive” and HEAD~# is the the number of commits from your branch history for your rebase.  Entering git rebase -i HEAD~3 will allow you to interact with the commits to cleanup any git history and/or address any merge conflicts.

pick 44d32e5 commit 1
pick f60bba8 commit 2
pick sdk898b commit 3
 

Here are some additional interactive features to use with  git rebase -i :

  •  pick  – the commit is included.
  •  reword  – allows you to change the commit message.
  •  edit  – you’ll be given the chance to amend the commit during the rebase. This is especially helpful when you run into merge conflicts.
  •  squash  – allows you to group multiple commits into a new commit. We have a guide for what happens when you squash in this blog post.
  •  fixup  – the commit is simply merged/sqaushed into the commit above it, and only one commit message is used to describe the change.

GitHub has a great article with additional detail on what happens in different scenarios during  git rebase --interactive .

Use git rebase to ensure you have a clean git history and can maintain a quality timeline to track when and what was committed.

For more information about how squashing affects your git history, check out An Illustrated Guide to Squashing in Git.

Ben Thompson

Ben Thompson

Ben Thompson is a co-founder at GitPrime where he leads design and customer experience. He is a Y Combinator alumni, with a background in product design, branding, and UX design. Follow @thebent on Twitter.

Get Engineering Impact: the weekly newsletter for managers of software teams

Keep current with trends in engineering leadership, productivity, culture, and scaling development teams.

how to use data to lead a successful software teams

A Data Driven Approach To Leading Software Teams

Get the definitive guide to understand how modern engineering teams are using data to become even more effective. We've analyzed over 20 Million commits to help you understand the important questions every software engineering manager needs to know.

Success! Please check your email for your download. You might also be interested in Engineering Impact: the Weekly Newsletter for Managers of Software Teams. Keep current with trends in engineering leadership, productivity, culture and scaling development teams.

Share This