Versions should map to identifiable source and artifacts. Release notes and compatibility rules help consumers interpret a change.
Before you start
You should understand commits, branches, the working tree and the staging area. Draw the commit graph before changing history. Try commands in a disposable repository with a clean working tree so you can observe exactly which references and files each operation changes.
The practical goal is to reason through this situation: Record commit, artifact digest and version for every release. Read the walkthrough first, then try the interview exercise before opening its answer. The important part is explaining the decision and its consequences, rather than remembering a definition alone.
Step-by-step walkthrough
Step 1: Map source to release
Record commit, version and artifact digest together.
Step 2: Keep deployment evidence
Know which artifact and configuration actually ran.
Step 3: Compare known-good state
Retrieve exact versions when diagnosing a regression.
Worked scenario
Record commit, artifact digest and version for every release.
A mutable release tag is moved after deployment. The name alone cannot prove which binary customers received. Stored deployment metadata ties the incident to an exact artifact and source tree, making reproduction and rollback more reliable than rebuilding whatever the tag currently names.
Common mistake
A mutable tag alone cannot prove which binary a customer received.
Verify the behavior
Retrieve the deployed artifact from metadata and verify its identity against the recorded source.
Interview exercise
Investigate a deployed regression.
Answer and reasoning
Use deployment metadata to retrieve the exact source and artifact, then compare behavior against the previous known-good version.
Continue learning
Compare the scenario with the Git and CI/CD interview questions and test your understanding with the Git and CI/CD MCQs. For terminology and implementation details, consult the reference material.