How to Identify the Breaking Commit With Git Bisect

Some code is broken, and you can’t figure out why. Maybe there are a lot of changes to consider, and identifying that breaking change seems impossible. Or, maybe you’re curious about how things generally break in your organization. The tool you need is git-bisect.

Git bisect conducts a binary search through your Git history to find a commit of interest. In this post, I’ll show how it works with an example.

A Caveat

For bisect to be useful, you must be committing atomically. If your practice is to squash-merge PRs, or commit swaths of unrelated code with each commit, a bisect may only tell you that something broke when you merged in a mega PR. That isn’t typically new or useful information.

Start the Bisect

Back to our scenario: you’re on main and something is broken. A white screen. A style regression. An inexplicable network error.

Tell Git this as your starting point with start:

$ git bisect start
 (git)-[main|bisect]-$

Now we’re at main in a bisect state, as you can read in the new prompt.

Mark a Bad Reference

The reference we have checked out, main is bad– it demonstrates the bad behavior. We note that this commit is broken with bad:

$ git bisect bad
 (git)-[main|bisect]-$

You can verify that it did something with git show, or any command that shows refs:

$ git show
commit 8bec317a (HEAD -> main, refs/bisect/bad)

Note the bad ref at the end.

Find a Good Reference

Now, we need to find a commit in the past where things worked. I usually jump back at least twenty commits to start. When in doubt, jump farther.

$ git checkout HEAD~20
Note: switching to 'HEAD~20'.

Test your code again. Is it still broken? If so, jump back the same amount of commits or more.

Once you find a place where it isn’t broken, that’s a ‘good’ commit. Let’s make a note:

$ git bisect good
Bisecting: 22 revisions left to test after this (roughly 5 steps)
[69d80fa4acjad4bd38e0b802ab87d4a6a3279c40] Merge pull request #8 from repo/branch

As the prompt explains, even though we’ve jumped back forty commits, we are only five steps from an answer!

Continue the Bisect

Now, we continue the bisect. Test your code on the new commit. Is it still broken? If so, make a note:

$ git bisect bad
Bisecting: 11 revisions left to test after this (roughly 4 steps)
[56988ajc43ab972baf43984a18f4580971cc2450] Remove deprecation warning

If it isn’t broken, swap good for bad.

Continue this process until there are no more commits to test. You’ll see a conclusion like this:

(git)-[v0.2.21~1|bisect]-$ git bisect bad
c66d2c2daja91def4aaaf107da9136c43861296f is the first bad commit
commit c66d2c2daja91def4aaaf107da9136c43861296f 
Author: Some Dev <dev@example.com>
Date:   Tue Aug 28 14:57:00 2018 -0700

    This might work? 😅

 example.gemspec | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Use show to learn more about your bad commit.

$ git show c66d2c2daja91def4aaaf107da9136c43861296f

Lastly, exit with reset (not stop or abort, as I often mistype 😡):

$ git bisect reset
Switched to branch 'main'

To summarize all the commands:

# Start
$ git bisect start

# Test your feature and confirm that it's broken
$ git bisect bad

# Travel backward n commits
$ git checkout HEAD~<n>

# Test your feature and find out if it works (or continue jumping back)
$ git bisect good

# Continue until the bad commit is identified...

Git Bisect Run With Automated Tests

Have a program that returns 0 for success or 1 for error, like a unit test? Use it to automate your bisect:

$ git bisect start
$ git bisect bad
$ git checkout <any good ref>
$ git bisect good
$ git bisect run <rspec spec/demonstrates_the_feature_spec.rb>

run will complete the entire bisect for you, using your test!

Conclusion

Why bother with this technique? Why not just find and fix the issue, and move on?

My advice is to try it a few times when you’re stuck debugging and see. When I have used it, I’ve felt like I’m able to answer a question that nobody else can within a reasonable amount of time. There’s something empowering and precise about saying “this broke in the Rails upgrade.” It turns your Git history into a useful resource for learning how to quickly fix things and how things break generally in your organization.

git-bisect is an incredible tool. I hope it helps you.

• Git
• Debugging