Concept and mechanism
A commit identifier references a history state, but a deployed application also depends on build process, configuration, and dependencies. Record the relationship between commit, artifact, and deployment. A moving branch does not stably identify the content of an earlier release. A tag can help name a version, but governance must define whether it may change and how artifact origin is verified.
Guided application
Bisect helps narrow a regression between known-good and known-bad references by evaluating intermediate versions. The test should represent the failure and be sufficiently deterministic. If a version cannot be evaluated, do not label it good merely to continue; use skip where appropriate and acknowledge possible ambiguity. If the environment changes between runs, separate code effects from configuration, data, and dependencies. An intermittent test may produce a wrong classification.
Export started failing between two releases. Reproduce the same sample and fix configuration in an exercise environment before classifying each bisect commit.
Common pitfalls
Treating main as proof of the deployed version; marking an untestable commit good; inferring causality from timing alone.
Related topics: Working tree, index, and commit · Branches, merge, and rebase
Investigation needs identified versions and a reproducible failure criterion.
Reference: Git: isolating regressions · Git 2.56; workflow concepts compatible with modern Git 2.x