Problems / bisect

git bisect start/good/bad

Finding bugs in code is usually straight forward; When a bug report comes in, you usually at least know where to look. But when we’re truly lost, we have no idea why a problem is happening, git bisect can come in really handy. It demonstrates git’s power, and enables you to hone into the commit that added the bug.

To start your bisect journey, stash or temporarily commit any unstaged changes in a branch, and then:

git bisect start

Label a version as bad

We don’t know how, but the current HEAD has a bug that we can’t find, so we can give this information to bisect.

git bisect bad

Git adds a new ref onto that commit called refs/bisect/bad, which you can see if you run git bisect visualize.

Find the last working version

The first thing we need to do, is go back in history until the bug wasn’t present. This could be some way back, but if you’re lucky it will be from the last deployment.

git tag


So let’s checkout 3.15.0, and see if the bug is present.

git checkout refs/tags/3.15.0

If the bug isn’t in this version, and that version is good, then lets tell bisect it’s a good version

git bisect good

Like when we tagged a bad version, git adds another new ref onto that commit called refs/bisect/good.

Binary search to the commit

Now that bisect has a start and end position, the bad commit is somewhere between the two. So it picks the middle commit, and sees if it’s good or bad. Using git bisect good/bad at stop, you tell bisect to prune one half of the remaining commits.

This is an extremely efficient process - if you have 256 commits to look over, it will take you a maximum of 8 steps - telling bisect at each stage if the bug is present or not.

Identifying the culprit

When you reach the end, bisect will present to you the first commit that caused the bad behaviour.

$ git bisect good
87b5eff012cbf1b467ca1141bc95a2684f726db6 is the first bad commit
commit 87b5eff012cbf1b467ca1141bc95a2684f726db6
Author: Andy Callaghan <[email protected]>
Date:   Tue Mar 26 11:30:24 2019 +0000

    forth commit

So look inside it, and then you should be able to see how & why that commit caused the bug you’re seeing

git show -p 87b5eff0

That’s about it for bisect - but now we’ll go into a little bit about how git stores revision history and references internally