Bisecting a Regression With git bisect Instead of Guessing
When a regression slips in somewhere across dozens of commits, git bisect finds the exact one with a binary search instead of a guessing spree.
At a job a few years back, a customer reported that a scheduled export had started silently dropping rows, and nobody could say when it broke because the export code itself had not changed in weeks. I burned most of an afternoon opening old commits one at a time and re-running the export by hand before a teammate asked why I was not just using git bisect.
git bisect automates the part I was doing manually: it does a binary search through your commit history to find the exact commit that introduced a bug. Start it with git bisect start, then tell it about one commit you know is broken with git bisect bad and one you know is fine with git bisect good <commit>. Git checks out a commit roughly halfway between the two and waits for you to test it. You mark that commit good or bad, and git bisect narrows the range again, cutting the number of commits to check in half each time. On a history of a few hundred commits, that is only a handful of steps instead of a linear crawl.
The real time savings come from git bisect run, which hands the testing step to a script instead of you. Point it at a script or command that exits 0 when the commit is good and non-zero when it is bad -- a specific unit test, a curl call that checks a response, whatever reproduces the bug reliably -- and bisect will check out each candidate commit, run the script, and keep narrowing the range on its own until it lands on the exact commit. You come back to a single commit hash and the diff that broke things, no manual testing required.
A few habits make this smoother. Tag or note a commit you are confident was good, such as your last release, before you start, so you are not guessing at the good end either. Run git bisect reset when you are done to return to the branch you were on -- bisect leaves you in a detached HEAD state while it works. And if the bug is flaky, write the test script to run the reproduction a few times and fail if any of them fail, since a single false negative during the search will send git bisect down the wrong half of the history.