How do tags and releases work in Git?

Question

Accepted Answer

**Tags** mark specific points in history as important — typically **releases** (versions like v1.0.0). Unlike branches, tags are fixed pointers that don't move, used to label and reference release versions. They're central to versioning and release management.

## Creating tags

```bash
# annotated tag (recommended for releases — has metadata: tagger, date, message)
git tag -a v1.0.0 -m "Release version 1.0.0"

# lightweight tag (just a pointer, no metadata)
git tag v1.0.0

# tag a specific past commit
git tag -a v1.0.0 <commit> -m "..."
```

**Annotated tags** (recommended for releases) store metadata (tagger, date, message); **lightweight tags** are just a name pointing to a commit.

## Working with tags

```bash
git tag                        # list tags
git show v1.0.0                # show a tag and its commit
git checkout v1.0.0            # check out the code at a tag (detached HEAD)

# tags are NOT pushed by default — push them explicitly:
git push origin v1.0.0         # push a specific tag
git push origin --tags         # push all tags
```

Important: **tags aren't pushed automatically** with `git push` — you push them explicitly.

## Tags vs branches

```text
BRANCH → a MOVABLE pointer that advances as you commit (ongoing development)
TAG    → a FIXED pointer to a specific commit (a permanent label — doesn't move)
→ Use tags to permanently mark releases/milestones; branches for ongoing work.
```

## Semantic versioning and releases

```text
SEMANTIC VERSIONING (SemVer): MAJOR.MINOR.PATCH (e.g. v2.3.1)
  MAJOR → breaking changes | MINOR → new features (compatible) | PATCH → bug fixes
→ Tags label these versions. Platforms (GitHub) build "Releases" from tags
  (with release notes, built artifacts) for distribution.
```

## Why it matters

Understanding tags and releases is valuable for **versioning and release management**, so it's useful practical knowledge for working with released software. **Tags** mark important points in history — typically **release versions** (like v1.0.0) — providing fixed, permanent references to specific commits, which is essential for tracking and referencing what code constitutes each release.

Understanding the distinction between **annotated tags** (recommended for releases, storing metadata like the tagger, date, and message) and lightweight tags is practical knowledge for proper release tagging.

Knowing how to create, list, and check out tags, and importantly that **tags aren't pushed automatically** (requiring explicit `git push origin --tags` or pushing specific tags — a common gotcha where people create tags but forget to push them), is necessary for correctly managing release tags.

Understanding **tags vs branches** (a tag is a fixed pointer to a specific commit — a permanent label that doesn't move — while a branch is a movable pointer that advances with development) clarifies their different roles: tags for permanently marking releases/milestones, branches for ongoing work.

Understanding the connection to **semantic versioning** (MAJOR.MINOR.PATCH conventions for communicating the nature of changes) and how platforms build **Releases** from tags (with release notes and artifacts for distribution) reflects how tags fit into real release management.

Since releasing and versioning software is a common need and tags are the Git mechanism for marking and referencing release versions (central to release management and integrated with platforms' release features), understanding tags and releases — annotated vs lightweight tags, pushing them, tags vs branches, and their role in versioning/releases — is valuable, practically-relevant Git knowledge for managing released software, a useful aspect of professional development connected to versioning conventions and release processes.