Git bisect: find the breaking commit without guessing

Reading fifty commits in order is optional. git bisect cuts the search space in half after every answer.

git bisect start
git bisect bad HEAD
git bisect good v2.4.0
# test, then: git bisect good | git bisect bad
git bisect reset

The whole method is three decisions: pick a reproducible failing test, mark one known-bad and one known-good revision, then let Git choose the midpoints. Automate the check with git bisect run and you barely touch the keyboard.

If a midpoint cannot be tested, use git bisect skip; too many skips reduce the certainty of the result.

The valuable output is not merely a commit hash—it is a small, reviewable change with a clear regression test.

Let the test answer for you

When a failure can be expressed as an exit code, automate the loop:

git bisect start HEAD v2.4.0
git bisect run npm test -- --runInBand regression.spec.ts

Exit 0 marks a revision good; a non-zero exit marks it bad. Use 125 from a wrapper script to skip a revision that cannot build, but inspect the final range when skips occur—Git may identify several possible first bad commits.

Bisect the smallest reproducible symptom

Avoid an end-to-end test that flakes or takes 20 minutes if a focused parser test can reproduce the bug. The result should lead directly to a regression test and a discussion of why review did not catch it, not merely a blame assignment.

Cover photo by Stanislav Kondratiev on Pexels.