Git Release Management
In this page:
git tag -a version_tag -m "release message"
git push remote_name version_tag
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
- Creating a tag locally and assuming it is on GitHub, when
git push origin v1.0.0orgit push --tagsis needed. - Using a lightweight tag for a release, missing the author, date and message that
git tag -arecords. - Reusing a version tag on a different commit, when a published tag should never move and a new version should be created instead.
- Collaboration relies on pull requests, code review, and forking to contribute to projects.
- Conflict resolution handles changes that overlap.
- Squashing commits and release management keep history and releases organized.
Chapter Quiz — Complete all 6 topics to unlock
0/6 topics done
Complete these topics first: