git tag
Mark specific commits as important milestones like releases or versions in your repository history.
You've just finished version 1.0 of your project and want to mark this exact
commit as the release. git tag creates a labeled reference to a specific
commit, giving you a human-readable name for important points in your history.
Tags are commonly used for version releases like v1.0.0, v2.1.3, or stable
checkpoints in development.
Running git tag v1.0.0 creates a lightweight tag pointing to your current
commit. This is simply a named reference—a pointer to a commit that doesn't
change. To see all tags, run git tag with no arguments. Tags are permanent
markers that make it easy to check out specific versions later with
git checkout v1.0.0.
Annotated tags store additional metadata:
git tag -a v1.0.0 -m "First stable release" creates a tag object with the
creator's name, date, and message. These are recommended for releases because
they capture more information about why the tag was created. You can see an
annotated tag's details with git show v1.0.0.
To tag an older commit, specify its SHA:
git tag -a v0.9.0 abc123 -m "Beta release". This is useful when you forgot to
tag a release at the time or need to retroactively mark commits.
By default, git push doesn't upload tags. To push tags to the remote, use
git push origin v1.0.0 for a specific tag or git push --tags for all tags.
Deleting tags requires git tag -d v1.0.0 locally and
git push origin --delete v1.0.0 on the remote.
In pull request workflows and CI/CD systems, pushing version tags often triggers deployment pipelines or GitHub releases. Teams use semantic versioning (v1.2.3) where the numbers indicate major.minor.patch versions, and tags mark each release for easy reference and rollback if needed.