Claude CodeAdvanced

How to Find Which Commit Broke a Test with Claude Code

Pair git bisect with Claude Code to locate the exact commit that introduced a regression and explain why.

9 minAdvanced

When a test that used to pass is suddenly red and you do not know why, git bisect finds the offending commit by binary search. Claude Code helps in two ways: it can script the bisect with a test command, and once the bad commit is found it can explain what in that change broke things. Together they turn a vague regression into a named commit and a clear cause.

What you need

  • Claude Code in the git repo
  • A known good commit (or tag) where the test passed
  • A reliable command that returns nonzero when the test fails

Step 1: Confirm a good and a bad commit

Identify a commit where the test passed and confirm it fails on HEAD. Bisect needs both ends of the range to search between them.

zsh - my-app
$git checkout v1.4.0 -- . && npx vitest run src/reports.test.ts
Tests 1 passed (1) # good
$git checkout HEAD -- . && npx vitest run src/reports.test.ts
Tests 1 failed (1) # bad
$

Step 2: Run an automated bisect

Ask Claude to drive git bisect run with your test command. Bisect checks out the midpoint, runs the command, and narrows the range automatically until it lands on the first bad commit.

git bisect start
git bisect bad HEAD
git bisect good v1.4.0
git bisect run npx vitest run src/reports.test.ts

Step 3: Read the culprit commit

Bisect reports the first commit where the test started failing. Have Claude show that commit and explain which line in it caused the regression.

Claude Code
You
Bisect points at commit 9a3f1c2 as first bad. Show that commit and tell me exactly what in it breaks src/reports.test.ts.
Agent
9a3f1c2 changed the date format from ISO to locale strings in formatReport. The test compares against an ISO string, so the assertion now fails. The change was intentional but the test was not updated.
Bisect names the commit; Claude explains the why.

Step 4: Reset bisect and fix the right thing

End the bisect session to return to your branch, then decide whether the commit was a real regression to revert or an intended change that needs the test updated. Here the format change was deliberate, so the test should be brought in line.

zsh - my-app
$git bisect reset
Previous HEAD position was 9a3f1c2 ... switching back
now update reports.test.ts to expect the locale format
$
Make the test command exit nonzero
git bisect run relies on exit codes: zero means good, nonzero means bad. Make sure your test command actually fails the process on a failing test, or bisect will mislabel commits.

Result: the regression is pinned to commit 9a3f1c2, explained as a deliberate date-format change, and resolved by updating the test rather than reverting a good change.

Watch related tutorials

Tags
#debugging#git-bisect#regression