← Back to Git Course | Chapter 7: Collaboration | Lesson 6 of 6

Git Release Management

Release management with tags is like putting a version sticker such as v1.0 on a finished product box, so anyone can find exactly what shipped.
Syntax
bash
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

bash
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

bash
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

bash
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

bash
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

bash
git checkout v1.0.0
Related Topics
{# common_mistakes/chapter_summary/browser_support: on Hindi pages the view already swaps in the hi_ translation fields (or blanks these out if untranslated), so this renders correctly for both languages without a lang_code check here. #}
Common Mistakes
  1. Creating a tag locally and assuming it is on GitHub, when git push origin v1.0.0 or git push --tags is needed.
  2. Using a lightweight tag for a release, missing the author, date and message that git tag -a records.
  3. Reusing a version tag on a different commit, when a published tag should never move and a new version should be created instead.
Chapter Summary
  • 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:

Login to run this code

C/C++/Java/PHP execution requires a free account. Your code is saved — you'll land right back in the editor after logging in.