Finding the commit that introduced a regression with git bisect

Goal

Identify the exact commit that changed behaviour from good to bad, in logarithmic time, even when the history contains hundreds of commits.

Prerequisites

A reproducible check that returns "good" or "bad" for a checkout, and one commit known to be good plus one known to be bad. A clean working tree, because bisect checks out commits.

Steps

1. git bisect start, then git bisect bad <bad-commit> and git bisect good <good-commit>.
2. If the check is manual, run it on the checked-out commit and answer with git bisect good or git bisect bad; Git picks the next midpoint.
3. If the check is scriptable, use git bisect run <script>: exit code 0 means good, 1-127 (except 125) means bad, and 125 tells bisect to skip a commit that cannot be tested (for example, it does not build).
4. When bisect reports the first bad commit, read its diff and message; then git bisect reset to return to the original branch.
5. Turn the check into a permanent regression test before fixing the cause.

Expected result

The first bad commit is identified after about log2(n) checks. The output names one commit, which is the starting point for the fix, not necessarily the root cause.

Limits and test basis

Bisect assumes a single transition from good to bad; intermittent failures or multiple independent causes confuse it. Commits that break the build must be skipped, which can widen the result to a range. The procedure follows the cited manual page.