Git Release Management
In this page:
Creating Software Releases with Tags
A tag marks a specific commit as a named milestone — most commonly a release version like v1.0.0 — so that commit stays easy to find and reference forever, independent of whatever branch it originally belonged to.
Example: Creating Software Releases with Tags
git tag v1.0.0
Creating Annotated Tags
An annotated tag (git tag -a v1.0.0 -m "message") stores its own author, date, and message as a real object in Git's database, unlike a lightweight tag which is just a bare pointer. For an official release, the annotated form documents who cut it and why, which matters when someone's auditing release history months later.
Example: Creating Annotated Tags
git tag -a v1.0.0 -m "First stable release"
Pushing Tags to the Remote Server
Tags live only in your local repository until you push them — git push origin <tagname> sends one, git push --tags sends all of them at once. Forgetting this step is a common surprise: the tag looks fine locally but nobody else can see it.
Example: Pushing Tags to the Remote Server
git push origin v1.0.0
git push --tags
Deleting Tags
Deleting a tag needs two separate commands because it exists in two places: git tag -d <name> removes it locally, and git push origin --delete <name> removes it from the remote — skipping the second means it reappears for anyone who fetches next.
Example: Deleting Tags
git tag -d v1.0.0
git push origin --delete v1.0.0
Checking Out Tagged Releases
git checkout <tagname> puts your working directory in the exact state it was in at that release, which is the standard way to reproduce a bug report against a specific shipped version or rebuild an old release exactly as it was.
Example: Checking Out Tagged Releases
git checkout v1.0.0
Chapter Quiz — Complete all 6 topics to unlock
0/6 topics done
Complete these topics first: