If you’ve read thoughtbot’s Git protocol guide, you’ll know that once a branch has been code reviewed, we encourage the branch’s author to use an interactive rebase to squash the branch down into a few commits with great commit messages.
It’s fairly common for a feature branch to be squashed down to somewhere between one and three commits before it’s merged. If you follow this protocol, or something like it, there are a few Git features that can make your interactive rebases quicker and easier.
Automate your rebases
Often, you’ll know before you commit something that it’s really just an extension of one of the other commits on your branch.
Say I have this history:
$ git log --oneline --decorate
ccc3333 (HEAD, my-feature-branch) A third commit
bbb2222 A second commit
aaa1111 A first commit
9999999 (main) Old stuff on main
One of my pull request reviewers points out a typographical error in one of my commits, so I thank the reviewer and fix the typo. The typo was introduced in “A second commit”, and before I merge I want to incorporate the fix into that commit: I want future git-blame(1) users find a useful commit that explains a meaningful change, and not a commit that immediately fixes a minor mistake.
I could just commit this change with a message like “fix typo” and worry about squashing it later, but then I have to remember which commit it fixes and manually re-order the list of commits in my interactive rebase. Git can do all of this automatically.
During an interactive rebase there are two ways to combine commits—fixup and
squash—and there are two corresponding options for the
git-commit(1) command, conveniently called --fixup and
--squash. These options instruct Git to write a commit message for us,
expressing the intention that this new commit will eventually be squashed (or
fixed up) with some existing commit.
For my typo fix, there’s no need to modify the original commit message so I can
use --fixup and pass the commit that I want my changes to become part of; it
handles the commit message for me:
$ git add .
$ git commit --fixup bbb2222
[my-feature-branch ddd4444] fixup! A second commit
Here’s what the history looks like now:
$ git log --oneline --decorate
ddd4444 (HEAD, my-feature-branch) fixup! A second commit
ccc3333 A third commit
bbb2222 A second commit
aaa1111 A first commit
9999999 (main) Old stuff on main
I’ve dealt with all of the feedback on my pull request, so I’m ready to rebase.
To take full advantage of the commit message git commit --fixup generated for
me, I need to pass the --autosquash option to git-rebase(1)
to tell Git to act the message:
git rebase --interactive --autosquash main
This is still an interactive rebase, so Git will still open an editor session
where I can manipulate the commits on our branch, but the --fixup commit I
made is already in the correct place in the list, and already marked with the
correct action:
pick aaa1111 A first commit
pick bbb2222 A second commit
fixup ddd4444 fixup! A second commit
pick ccc3333 A third commit
Always be automating
Since git rebase --interactive --autosquash only picks up on commits with a
message that begins fixup! or squash!, and Git still gives you the chance to
to move things around in your editor like a regular interactive rebase, you
might be wondering why we don’t just use --autosquash by default?
Don’t worry, Git’s got you covered there too. The rebase.autosquash setting
will enable this useful little feature for all interactive rebases:
git config --global rebase.autosquash true
If you’re using a recent version of thoughtbot’s dotfiles, then you’ve already got this enabled.
Type words, not SHAs
While --autosquash made that interactive rebase fairly painless, it could
have been even easier.
When I ran the command git commit --fixup, I had to tell Git which commit my
new changes should be merged with. In the example above I used the first few
characters of the commit’s SHA—bbb2222—lifted from the output of git
log, but I could have referred to the commit in any of the various ways Git
allows.
The one I reach for most often in this situation is referring to the commit
using some text that appears in its commit message: Git will interpret :/foo
as “the most recent commit that contained the string foo in the first line of
it’s commit message”. In our example above, I could have done this:
git commit --fixup :/second
Because this technique finds the most recent commit that matches the search string, it’s not great for finding things a long way back in history, but it’s perfect for this kind of situation where we just want to quickly and accurately identify one of the last half dozen commits.
Want more?
If you found this useful, you might be interested to know that I’m writing a book called Goal-Oriented Git. It’s all about using Git effectively in everyday situations.
