Git Bisect Debugging
Trigger Boundary
- •Use when there is a known good revision and known bad revision.
- •Do not use when no deterministic pass-fail check exists.
- •Do not use for dependency vulnerability triage; use
security-vulnerability-management.
Goal
Isolate the first bad commit with objective pass-fail evidence.
Shared Git Contract (Canonical)
- •Use
../git-branch-strategy/references/git-governance-contract.mdas the single schema and gate source. - •Track bisect artifacts with
GIT-BIS-*IDs. - •Run machine validation:
python3 ../git-branch-strategy/scripts/validate_git_contract.py --manifest <path/to/manifest.json>.
Inputs
- •Known good commit and known bad commit
- •Deterministic test or script for bisect classification
- •Environment requirements for reproducible execution
Outputs
- •
GIT-BIS-*culprit commit evidence - •Bisect log with classified steps
- •Next-step fix or revert recommendation
Workflow
- •Confirm deterministic reproduction with good and bad endpoints.
- •Start bisect and classify midpoint commits.
- •Automate classification when possible for consistency.
- •Validate culprit commit by replaying test around boundary.
- •Publish culprit evidence with contract validation record.
Quality Gates
- •Good/bad endpoints are validated before bisect starts.
- •Classification command is deterministic and documented.
- •Culprit commit is confirmed by repeatable verification.
- •Bisect session log is preserved for auditability.
Failure Handling
- •Stop when classification is flaky or environment-dependent.
- •Escalate when multiple interacting commits mask single-commit isolation.