Protocol
Bisect the version history instead of inspecting every change
The last edit is a suspect, not automatically the culprit.
When it fits
- The same test passed in an earlier version and fails now.
When to avoid it
- Repeated introduction and removal of a bug, changing dependencies or flaky tests can invalidate a simple one-transition story.
Why it matters
Choose a reproducibly passing version and a failing version. Test a version between them, then keep the half containing the transition. Continue until the boundary is narrow enough to inspect. Git bisect automates this search for code history.
Steps
- Use the same input, test and relevant environment across versions.
- Record untestable versions as unknown, not as failures.
- Confirm the candidate boundary with a fresh run and inspect the actual change.
An example
A mapping worked in release A and breaks in H. Testing D and then F narrows the investigation without reading every transport first.
Check your result
The report names the tested boundary and any skipped versions that prevent a precise conclusion.
Keep this limit in mind
- Repeated introduction and removal of a bug, changing dependencies or flaky tests can invalidate a simple one-transition story.
Evidence and sources
Supports
Git bisect narrows a known-good to known-bad version interval through repeated tests; skipped versions can leave an ambiguous boundary.
A first failing version is an investigation lead, not proof of a complete root cause.
git-bisect: Use binary search to find the commit that introduced a bug · Description; Bisect skip