← Git: team decisions and recovery
05 / 5 · 18 MIN

Diagnosis and release traceability

Connect incidents to artifacts and locate relevant changes with evidence.

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.

IN PRACTICE

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

Take this idea with you

Investigation needs identified versions and a reproducible failure criterion.

Create account

Reference: Git: isolating regressions · Git 2.56; workflow concepts compatible with modern Git 2.x