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
badWe 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.
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
...
3.14.1
3.15.0
3.16
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.
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.
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