Tools & Workflow

Git Bisect for a Small Regression

Find the first bad commit with Git bisect, first manually and then with a narrow automated test.

1 min read
#git#bisect#debugging#testing

People watching a blue sunrise over mountain ridges

Photo: Unsplash.

When a regression appeared somewhere across fifty commits, reading them in order is rarely the fastest path. git bisect performs a binary search between a known good and known bad revision.

Start with a clean working tree:

git bisect start
git bisect bad HEAD
git bisect good v1.8.0

Git checks out a midpoint. Run the smallest test that answers one question: does this revision contain the regression?

npm test -- search-index
git bisect good   # test passed
# or
git bisect bad    # regression reproduced

After several rounds, Git identifies the first bad commit. Return to the original branch with:

git bisect reset

If the test is reliable and exits 0 for good or 1–127 (except 125) for bad, automate it:

git bisect start HEAD v1.8.0
git bisect run ./scripts/reproduce-search-regression.sh

Exit 125 means the revision cannot be tested, which is useful when an intermediate commit does not build. Keep the script narrow; a flaky integration suite can make the search confidently wrong.

The commit found by bisect is evidence, not automatically the correct place to patch. Read the change and reproduce the failure once more. A commit can expose an older bug or depend on state outside the repository.

Reference