Hoe werken tags en releases in Git?

Question

Accepted Answer

**Tags** markeren specifieke punten in de geschiedenis als belangrijk — meestal **releases** (versies zoals v1.0.0). In tegenstelling tot branches zijn tags vaste aanwijzers die niet bewegen, gebruikt om releaseversies te labelen en ernaar te verwijzen. Ze zijn centraal voor versiebeheer en release management.

## Tags maken

```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 "..."
```

**Geannoteerde tags** (aanbevolen voor releases) slaan metadata op (tagger, datum, bericht); **lichte tags** zijn slechts een naam die naar een commit wijst.

## Werken met 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
```

Belangrijk: **tags worden niet automatisch gepushed** met `git push` — je pusht ze expliciet.

## Tags versus 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 en 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.
```

## Waarom het belangrijk is

Inzicht in tags en releases is waardevol voor **versiebeheer en release management**, dus het is nuttige praktische kennis voor het werken met uitgebrachte software. **Tags** markeren belangrijke punten in de geschiedenis — meestal **releaseversies** (zoals v1.0.0) — en bieden vaste, permanente verwijzingen naar specifieke commits, wat essentieel is voor het volgen en refereren van welke code elke release bevat.

Inzicht in het onderscheid tussen **geannoteerde tags** (aanbevolen voor releases, waarin metadata wordt opgeslagen zoals de tagger, datum en bericht) en lichte tags is praktische kennis voor correct release tagging.

Weten hoe je tags maakt, afspeelt en uitcheckt, en belangrijk dat **tags niet automatisch worden gepushed** (waarvoor expliciet `git push origin --tags` of pushen van specifieke tags vereist is — een veelvoorkomend pitfall waarbij mensen tags maken maar vergeten ze te pushen), is nodig voor correct release tag management.

Inzicht in **tags versus branches** (een tag is een vaste aanwijzer naar een specifieke commit — een permanent label dat niet beweegt — terwijl een branch een beweegbare aanwijzer is die vooruitgaat met development) verduidelijkt hun verschillende rollen: tags voor het permanent markeren van releases/mijlpalen, branches voor lopend werk.

Inzicht in de verbinding met **semantic versioning** (MAJOR.MINOR.PATCH-conventies voor communicatie over de aard van veranderingen) en hoe platforms **Releases** uit tags opbouwen (met release notes en artefacten voor distributie) weerspiegelt hoe tags in werkelijk release management passen.

Omdat het uitbrengen en versiëren van software een veel voorkomende behoefte is en tags het Git-mechanisme zijn voor het markeren en refereren van releaseversies (centraal in release management en geïntegreerd met release-features van platforms), is inzicht in tags en releases — geannoteerde versus lichte tags, ze pushen, tags versus branches, en hun rol in versiebeheer/releases — waardevol, praktisch relevant Git-kennis voor het beheren van uitgebrachte software, een nuttig aspect van professionele development verbonden met versieconventies en release processen.