Creating Tags

The Hook (The "Byte-Sized" Intro)

Creating a tag takes one command. But choosing the right type of tag matters. Lightweight tags are quick labels — no metadata, no signature, no message. Annotated tags are full Git objects with your name, the date, and a description baked in. For releases, always go annotated. For personal bookmarks, lightweight is fine.

📖 What is Creating Tags?

Creating a tag means attaching a named label to a specific commit. You choose between lightweight (quick pointer) and annotated (full metadata tag).

Conceptual Clarity

Creation commands:

Goal	Command	Type
Quick label at HEAD	`git tag v1.0`	Lightweight
Release tag at HEAD	`git tag -a v1.0 -m "msg"`	Annotated
Tag a past commit	`git tag -a v0.9 abc123 -m "msg"`	Annotated
GPG-signed tag	`git tag -s v1.0 -m "msg"`	Signed

What gets stored:

Data	Lightweight	Annotated
Tag name	✅	✅
Commit reference	✅	✅
Tagger name/email	❌	✅
Date	❌	✅
Message	❌	✅
GPG signature	❌	Optional

Real-Life Analogy

Lightweight tag = Sticking a Post-it note on a page ("Important!")
Annotated tag = Stamping the page with a date, your signature, and a note explaining why it matters

Visual Architecture

flowchart LR COMMIT["📌 Commit abc123"] --> LW["🏷️ Lightweight<br/>Just a name"] COMMIT --> AN["🏷️ Annotated<br/>Name + Author + Date + Message"] style LW fill:#1a1a2e,stroke:#ffd700,color:#ffd700 style AN fill:#0f3460,stroke:#53d8fb,color:#53d8fb

Why It Matters

Release documentation: Annotated tags record who created the tag and why.
Auditing: GPG-signed tags prove authenticity for security-sensitive releases.
Convention: Most teams require annotated tags for production releases.
Automation: CI/CD systems often differentiate between tag types.

Code

bash

# ─── Lightweight tag (quick bookmark) ───
git tag v1.0.0
# Tags HEAD, no metadata

# ─── Annotated tag (recommended for releases) ───
git tag -a v1.0.0 -m "Production release: user authentication"
# Stores: your name, email, date, message

# ─── Tag a specific past commit ───
git log --oneline -5        # Find the commit
git tag -a v0.9.0 abc1234 -m "Beta pre-release"

# ─── GPG-signed tag (verified authenticity) ───
git tag -s v1.0.0 -m "Signed production release"
# Requires GPG key configured

# ─── Verify what was created ───
git show v1.0.0
# Annotated: shows tagger, date, message, then the commit
# Lightweight: shows only the commit

# ─── Common naming convention ───
# v1.0.0    → production release
# v1.0.0-rc1 → release candidate
# v1.0.0-beta → beta release

Key Takeaways

Use annotated tags (-a -m) for releases — they store who, when, and why.
Use lightweight tags for quick local bookmarks.
You can tag any commit, not just HEAD — pass the SHA after the tag name.
Follow a consistent naming convention like v1.0.0.

Interview Prep

Q: How do you create an annotated tag on a previous commit? A: git tag -a v1.0.0 <commit-sha> -m "Release message". The SHA specifies which commit to tag, and -a -m makes it annotated with metadata.
Q: What is a GPG-signed tag and why would you use one? A: A signed tag (git tag -s) includes a GPG cryptographic signature proving the tag was created by someone with the matching private key. It's used for security-sensitive releases to verify authenticity and prevent tampering.
Q: Why are annotated tags recommended over lightweight tags for releases? A: Annotated tags store the tagger's identity, timestamp, and a message — providing context and auditability. Lightweight tags are just pointers with no metadata, making them unsuitable for tracking who tagged a release and why.