Article summary
It’s likely you have heard about git-bisect plenty of times before. Hopefully, it’s not a tool that you need to reach for often, since it essentially indicates that there’s something wonky or broken, and your best hope for identifying the actual problem is to look back in time.
Despite this, sometimes git-bisect is the right tool, and if you don’t have any familiarity with it, you might not use it when you should. To that end, I’ll share a couple of strategies I’ve found helpful.
1. Think Carefully about Your Fitness Function
This is the most important aspect of using git-bisect. You need to know what you are seeking. You should ask yourself whether you can make a binary pass/fail decision for each commit under consideration. If you’re lucky, there’s something obvious like a failing test. But sometimes the problem is a bit more nebulous.
Let’s consider a mysterious memory leak as an example. One idea is to run the full test suite with a memory limit and see whether it exceeds the limit. What would you learn from this? It’s possible that a test would zero in on the precise commit that introduced a very big memory leak. On the other hand, it’s also possible that there’s been a long-standing small memory leak that’s slowly worsening over time as you add more tests.
I highly recommend taking the time up front to consider what you’re measuring and what you’ll learn from each specific metric you’re considering.
2. Automate It
Resist the urge to jump into a git-bisect without some level of automation. If you do, and you find a significant number of commits to search, you’ll likely start to question whether you’re spending your time wisely. Perhaps you’ll even quit looking.
In practice, it’s not actually that hard to make a shell script that does a few things like:
- Run Yarn to get your node_modules at the correct versions
- Patch a few source files (git-diff is good at creating these)
- Run your tests
Even better, once you’ve gotten to this point, git-bisect has an awesome feature, git bisect run, which will repeatedly run your script on each commit it’s testing. A zero return code will be interpreted as the commit being good. Otherwise, (with a caveat), git-bisect will treat the commit as bad.
You can basically walk away and let it test your history. Even better: You could create a new Git worktree and run git-bisect from within it. Meanwhile, you can continue working on your main work tree.
I hope these tips can help you make better use of git-bisect on the rare occasion you’ll need it.