Git bisect is one of those Git features that seems obvious once discovered, but somehow flies under the radar for most developers, including me.
It’s a binary search algorithm built into Git that helps find the exact commit where a bug was introduced. Instead of manually checking out commits one by one, it narrows down the range until it finds the culprit.
This is a huge drop in complexity because we only need to check commits in the worst case scenario.
Here’s how it works in practice. Say there’s a bug in the current version, but the application was working fine two weeks ago.
To start the process, we only need to tell Git about the latest good commit (usually the latest stable release) and a more recent commit where the bug is present.
git bisect start
git bisect good <commit>
git bisect bad <commit>
Now, instead of manually checking every commit since the latest good commit, Git bisect starts by checking out a commit in the middle of that range.
The developer can test it and mark it as good or bad.
git bisect good
git bisect bad
Git then picks another commit halfway between the known good and bad points, and the process repeats until the exact problematic commit is found.
Sure, it’s not an everyday tool, but when you need it, it’s a lifesaver.