Most of the comments to my recent articles on 3 Git commands I use every day and When to make a Git commit have mentioned using git rebase.

So, let's talk about git rebase. Jumping right in, I use git rebase for two reasons:

1. To bring a stale branch up to date.
2. To change a set of unmerged commits.

Let's take a closer look at both of these.

Bringing a branch up to date

For some, git rebase falls on the magic end of the spectrum for Git commands. Yet, if we break down the actions taken by git rebase we can understand the magic.

While a tree is the goto analogy when visualizing Git commands, I find video editing also helps describe git rebase.

In the case of bringing a stale branch up to date, let's consider the following tree progression.

Starting with the full tree, we have a stale branch (in red) off a master branch. If we zoom in, we see the branch is stale because it's missing the recent commits from master (in blue).

When we run git rebase, it first will rewind both branches back to the first point when their commit history matches (in gray). From this point, git rebase will fast-forward through the commits on the master branch and apply them to the stale branch. Finally, git rebase replays the commits from the stale branch.

The resulting tree is as if you just created a new branch off master and made your commits. In doing so, git rebase facilitates a clean merge.

Changing a set of commits

I also like to use git rebase to change a set of commits. Often these are quick commits I made on a feature branch I want to clean up before merging. Either by condensing commits or improving their commit messages.

To do so, I'll run git rebase -i. The -i stands for interactive, because git rebase allows you to edit the commit list.

The output looks similar to the output from git log --oneline. However, each commit is prefixed with a command. The comments contain a legend for each of the commands.

I'll commonly use r to reword a quick commit and f to fixup a commit into the previous commit without changing the message. Although many people talk about squashing a commit, I use fixup far more often than squash as the latter requires an extra step of editing the commit messages.

Upon saving, git rebase -i will replay these commits using the commands you specified.

A few caveats

• There can be conflicts.
• The replayed commits get a new commit SHA.

If you're making small, cohesive commits (as outlined in When to make a Git commit) any conflicts should be easy to resolve.

Finally, it's important to note that git rebase will change the SHA of any replayed commits. So if you shared your commits with others or merged them into another branch, Git will no longer see these commits as being the same.

Want to Master more Git commands? This post was adapted from my video series Getting Git. It contains over 50 videos covering Git commands as well as scenarios you'll encounter using Git every day. The Master: git rebase is available on Vimeo.

Find this interesting? Let's continue the conversation on Twitter.