Day 11/13 of Git 101 Series
Tags and Releases
Concept Explanation
Tags provide a permanent marker on specific commits. They are often used to label versions such as v1.0 or v2.3. Git supports two types of tags.
Lightweight tags act like simple bookmarks. They only store a reference to a commit.
Annotated tags behave like full Git objects. They store metadata such as the author, date, and a custom message. Annotated tags are preferred for releases because they preserve detailed version history.
Commands
git tag <name>
Creates a lightweight tag.
git tag -a <name> -m <message>
Creates an annotated tag.
git show <tag>
Displays tag information.
git push origin <tag>
Pushes a specific tag to the remote.
git push origin --tags
Pushes all local tags to the remote.
Example
You finish a major feature and decide to publish version 2.0.
You run:
git tag -a v2.0 -m "version 2.0 stable release"
followed by:
git push origin v2.0
This creates a permanent labeled point in your repository that developers can always refer back to.
Real World Use Case
Software teams use tags when releasing stable versions. CI systems detect these tags to trigger build pipelines that generate release binaries. Package managers rely on these tags to fetch specific versions. Tags turn a moving timeline of commits into meaningful checkpoints users and developers can trust.
Under the Hood Explanation
A lightweight tag is a simple pointer stored under refs/tags. It has no separate object.
An annotated tag creates a tag object in the Git database. This object stores the target commit hash, tag message, type information, and a GPG signature if provided. When Git resolves a tag, annotated tags require dereferencing the tag object before reaching the underlying commit. This design enables richer metadata and cryptographic signing for trusted releases.
Tomorrow: Day 12/13 of Git 101 Series, Reset Revert