Using git bisect to track down bugs
Something in your application worked a few days ago, and now it doesn’t. Aararrgh! We’ve all been there. Nobody has any idea which change broke it. You use git log -p to thrawl through the recent changes, but nothing stands out. What to do, what to do? Use git bisect to minimize or completely automate finding the commit that broke it!
Run git bisect start to begin. Since the current version is bad, you run git bisect bad to let git know.
Now you need to tell it which commit/version is the latest “good one” - often that’d be the last released tag, so for example git bisect good v25.0.3.
git will now decide on a commit you should test, check it out and tell you how many are left.
If you are just testing manually, you’ll now manually run your tests and tell git if it’s good or bad. In our web environment that’d often involve restarting the application (just to make sure) and then running the tests.
When you know if this revision has the bug or not, you run git bisect bad if it’s bad and git bisect good if things are good and after a little while of that git will tell you which commit introduced the bug!
If you can do the ‘is it good or bad’ test automatically, you can run ‘git bisect run command’ (where command is make, prove t/sometest.t or a custom shell script) and git will figure it out automatically while you get coffee or go to lunch!
