Day 53beginnerMar 25, 2026

Tag Releases Like a Pro with Semantic Versioning

Annotated tags with semantic versioning give your releases clear identity, making deployments and rollbacks predictable.

gitreleasesversioning

What

Git tags mark specific points in history, typically used for releases. Annotated tags (created with -a) store the tagger's name, date, and a message, making them proper Git objects. Combined with semantic versioning (vMAJOR.MINOR.PATCH), they provide clear, meaningful release markers that tools and CI/CD pipelines can rely on.

Why It Matters

Without tags, releases are just arbitrary commits with no clear identity. Tags give you instant rollback targets, changelog anchors, and deployment markers. Annotated tags are especially important because they're timestamped and carry context. Many CI/CD tools trigger deployments automatically when a new tag is pushed.

Example

# Create an annotated tag for a release
git tag -a v1.0.0 -m "Initial release"

# Create a tag for a patch release
git tag -a v1.0.1 -m "Fix login redirect bug"

# Tag a specific older commit
git tag -a v0.9.0 -m "Beta release" abc1234

# List all tags
git tag -l

# Show tag details
git show v1.0.0

# Push a single tag to remote
git push origin v1.0.0

# Push all tags to remote
git push origin --tags

# Delete a tag locally and remotely
git tag -d v1.0.0
git push origin --delete v1.0.0

bash

Common Mistake

Using lightweight tags (git tag v1.0.0 without -a) instead of annotated tags for releases. Lightweight tags are just pointers to a commit with no metadata — no author, no date, no message. They're fine for temporary local bookmarks but lack the context needed for proper releases.

Quick Fix

Always use git tag -a for releases. Follow semantic versioning: increment MAJOR for breaking changes, MINOR for new features, PATCH for bug fixes. Set up a CI/CD trigger on tag pushes to automate your release pipeline.