Tag an older commit in Git
Create an annotated or lightweight tag at a verified historical commit, publish only the intended tag, and account for tag-triggered automation.
Pass the historical commit as the target of git tag. For an annotated release tag:
git log --oneline
git show --stat a1b2c3d
git tag -a v1.0.0 a1b2c3d -m "Release v1.0.0"
Replace the example hash with the verified release commit. Creating the tag does not change the checked-out branch or move its tip. A release tag identifies a particular object, normally a commit, rather than following a branch as it advances.
Choose the tag type
These are alternatives:
# Lightweight tag
git tag v1.0.0 a1b2c3d
# Annotated tag
git tag -a v1.0.0 a1b2c3d -m "Release v1.0.0"
An annotated tag has its own message, tagger identity, and timestamp, and can be signed. Its creation date normally reflects when you create the tag, not the historical commit's date. This is expected when tagging a past release retrospectively.
Verify and publish one tag
git show v1.0.0
git rev-parse 'v1.0.0^{commit}'
git push origin refs/tags/v1.0.0:refs/tags/v1.0.0
The peeled revision prints the target commit ID. The explicit tag ref avoids ambiguity with a branch named v1.0.0.
Before pushing, check release automation. A tag push can trigger a build or deployment even when its target commit is old, but whether it does depends on the hosting platform, event filters, permissions, and workflow configuration. Creating a tag does not itself prove a release artifact was built.
Add several historical tags
Map each version to a verified commit using release records or a changelog, then create the tags individually. Publish the reviewed refs explicitly:
git push origin refs/tags/v0.9.0 refs/tags/v1.0.0
git push origin --tags sends all local tags eligible for the push, including unrelated ones you may have created for local work. Use it only when that entire set is intended.
FAQ
What if the local tag points at the wrong commit?
If it has not been published or consumed, delete and recreate it after inspecting the correct target. Recreating an annotated tag also recreates its tag object and metadata.
What if the tag is already public?
Prefer a new corrected tag when people or automation depend on the old one. Deleting and recreating a remote tag does not update copies held by other clones and can create inconsistent meanings for the same version name. Coordinate any replacement explicitly.
Can I tag a commit that is not on the current branch?
Yes, provided the object exists locally and the revision resolves. Fetch missing history if necessary. Inspect the target tree and test or verify the historical release before assigning a version name.
Contact us
Join the community
to join the community
Try Guance
Start online and pay only for what you use.
Get startedChoose a Guance plan