Skip to content

Summary: Releases and tags

A release is a tagged commit + release notes + an announcement. All the ceremony reduces to these three things.

Terminal window
git tag -a vX.Y.Z -m "Release vX.Y.Z: description" # create annotated tag
git tag # list tags
git tag --sort=-v:refname # list, sorted version-aware
git show vX.Y.Z # tag details
git push origin vX.Y.Z # push one tag
git push origin --tags # push all tags
git fetch --tags # fetch tags from remote
git tag -d vX.Y.Z # delete tag locally
git push origin --delete vX.Y.Z # delete tag on remote
MAJOR.MINOR.PATCH
  • MAJOR: incompatible changes (breaking)
  • MINOR: new features, backward-compatible
  • PATCH: bug fixes, backward-compatible

Pre-release: vX.Y.Z-alpha.1, vX.Y.Z-beta.3, vX.Y.Z-rc.1.

# vX.Y.Z - YYYY-MM-DD
## Highlights
## Breaking changes
## New features
## Improvements
## Bug fixes
## Migration notes
## Contributors

Not every release needs every section. Patch releases might only have “Bug fixes.”

WorkflowHow releases work
GitHub FlowTag specific main commits; deploys are continuous regardless
GitFlowCut release/* branch, QA, merge to main + develop, tag main
Trunk-basedOften automated; tag specific trunk commits, auto-generate notes
ForkingMaintainer is the release authority; internal workflow drives mechanics
  • Users want what’s new, what’s fixed, what’s broken
  • Operators want deploy expectations, migration steps
  • Developers want API changes, deprecations
  • Auditors want a complete record

You can tag, version, and release any project. L11 covers two more primitives, cherry-pick (move commits between branches) and stash (save in-progress work). Both are tools for advanced workflows.

Git stores snapshots. Every other command is just navigating those snapshots.

A tag is an immutable label on a specific snapshot. A release is that snapshot’s human-readable explanation.