The library catalog sync tool reached a build the team wants to mark as releasable for operations. How should that milestone be recorded in Git?
Select an answer to reveal the explanation.
Short Explanation
A version tag is a gold star on the exact commit ops can redeploy — like labeling a boxed catalog build ‘shelf-ready.’ Renaming remotes or sprinkling TODOs does not pin a releasable municipal build.
Full Explanation
When the library catalog sync tool reaches a build operations should treat as releasable, Git needs an immutable pointer to that exact commit. Creating an annotated or version tag labels the stable commit so deploy pipelines, runbooks, and rollback procedures can check out or reference a known good revision rather than guessing which tip of main was blessed.
Renaming the remote to stable does not mark a commit and confuses remotes with release state. Adding TODO comments in random source files is not a release marker and pollutes code. Deleting feature branches and assuming unmarked main is always releasable ignores that main may contain unreleased commits and provides no durable label for operators.
Exam caveat: annotated tags store tagger metadata and a message; lightweight tags can work but annotated/SemVer tags are preferred for municipal releases. Operational check: tag the release commit, push the tag, deploy from that tag in a staging job, and confirm git describe or the pipeline ref resolves to the intended SHA. Operations should record the tag in the change ticket and deployment runbook for the catalog sync tool so rollback instructions cite the prior tag explicitly rather than “whatever main was last Tuesday.”