Skip to content
← Back to blog

Git Bisect for Bug Hunting: Finding Exactly When a Regression Was Introduced

AP Track Team ·

The Regression Mystery

Regressions are among the most frustrating bugs because they involve functionality that previously worked. Something changed that broke it, but in a repository with hundreds of commits per week, finding the culprit manually is like searching for a needle in a haystack. Git bisect transforms this search from a linear scan into a binary search, dramatically reducing the number of commits you need to check.

How Git Bisect Works

Git bisect performs a binary search through your commit history. You tell it a known good commit where the feature worked and a known bad commit where it is broken. Git bisect then checks out the midpoint commit and asks you to test it. Based on your response — good or bad — it narrows the range by half and checks out another commit. Repeat until the first bad commit is identified.

Running a Bisect Session

Start with git bisect start, then mark the boundaries with git bisect bad for the current broken state and git bisect good <commit-hash> for the last known working state. Git checks out a commit for you to test. After testing, run git bisect good or git bisect bad to record the result. For a range of one thousand commits, you will find the culprit in about ten steps.

Automating the Bisect

If you can write a script that tests for the bug automatically, use git bisect run <script>. Git will execute your script at each bisect step, using the exit code to determine good or bad. A fully automated bisect can find the responsible commit in seconds, even across thousands of commits. This is especially powerful for regressions that have automated test coverage.

From Bisect to Bug Report

Once you identify the commit that introduced the regression, you have all the information needed for a precise bug report. The commit message explains what was changed, the diff shows exactly what code was modified, and the author knows the intent behind the change. Include this information in your AP Track bug report to give the developer maximum context for the fix. A bug report that says "introduced by commit abc123" is far more actionable than one that says "this used to work."