Release tags

Release tags bind a version label to an exact commit for reproducible builds, changelog generation, deployment traceability, and rollback targeting.

					git tag -a v2.4.0 -m "Release 2.4.0"
git push origin v2.4.0
# CI workflow: on push tag v* → build artifact, publish, deploy
				

| Practice | Reason | |----------|--------| | Annotated tags on releases | Metadata and signing support | | Immutable published tags | Artifacts and deployments reference them | | SemVer alignment | Communicate breaking vs patch intent | | Changelog from commits | Requires good messages between tags |

On interviews: annotated vs signed tags, protected tags, SemVer, CI/CD triggered by tags, retag policy.

Common pitfalls: retagging a published release; lightweight tags without release metadata; tagging before final merge lands.

The trade-off is strict release immutability versus hotfix processes that need a new patch version instead of moving a tag.

Checklist:

• Tag the exact commit that shipped.
• Protect release refs on the remote.
• Tie tags to artifacts and changelogs.
• Publish corrective releases as new versions, not moved tags.