So, let's talk about
git rebase. Jumping right in, I use
git rebase for two reasons:
- To bring a stale branch up to date.
- To change a set of unmerged commits.
Let's take a closer look at both of these.
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
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.
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.
git rebase -i will replay these commits using the commands you specified.
- 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.