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
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.
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.
... 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
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