Using tags
Configure tags to organize the source control repository
Tags mark points in history
A tag names a specific commit. Unlike a branch, it does not move — which is precisely why it is the right way to record "this is what we shipped as v2.4.1".
| Kind | Contains |
|---|---|
| Lightweight | Just a pointer to a commit |
| Annotated | A tagger, date, message — and can be signed |
Prefer annotated tags for releases. The metadata answers who created it and when, and a signed tag lets a consumer verify authenticity — neither of which a lightweight tag can do.
Tags in a release process
| Use | Value |
|---|---|
| Mark the released commit | The rollback and hotfix branch point |
| Trigger a release pipeline | Tag-based triggers |
| Correlate deployment to source | The version in production maps to a commit |
That first row connects to the hotfix path: branching from the released tag is what isolates a fix from unreleased work on main.
Discipline
Tags are not immutable by nature — they can be deleted and re-pointed — but treating them as immutable is what makes them trustworthy. A tag that moves is worse than no tag, because everything that recorded "v2.4.1" now refers to something else. Protect release tags and never re-point one.
Primary sources