Wie funktionieren Tags und Releases in Git?

Question

Accepted Answer

**Tags** markieren spezifische Punkte in der Historie als wichtig — typischerweise **Releases** (Versionen wie v1.0.0). Im Gegensatz zu Branches sind Tags feste Zeiger, die sich nicht bewegen, und werden verwendet, um Release-Versionen zu bezeichnen und zu referenzieren. Sie sind zentral für Versionierung und Release-Management.

## Tags erstellen

```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** (empfohlen für Releases) speichern Metadaten (Tagger, Datum, Nachricht); **Lightweight Tags** sind nur ein Name, der auf einen Commit zeigt.

## Arbeiten mit 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
```

Wichtig: **Tags werden nicht automatisch mit `git push` übertragen** — Sie müssen sie explizit pushen.

## 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 und 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.
```

## Warum es wichtig ist

Das Verständnis von Tags und Releases ist wertvoll für **Versionierung und Release-Management**, daher ist es praktisches Wissen für die Arbeit mit veröffentlichter Software. **Tags** markieren wichtige Punkte in der Historie — typischerweise **Release-Versionen** (wie v1.0.0) — und bieten feste, dauerhafte Referenzen zu spezifischen Commits, was für die Verfolgung und Referenzierung des Codes in jedem Release unverzichtbar ist.

Das Verständnis des Unterschieds zwischen **Annotated Tags** (empfohlen für Releases, speichern Metadaten wie Tagger, Datum und Nachricht) und Lightweight Tags ist praktisches Wissen für korrektes Release-Tagging.

Zu wissen, wie man Tags erstellt, auflistet und checkt, und wichtig — dass **Tags nicht automatisch gepusht werden** (was explizites `git push origin --tags` oder das Pushen spezifischer Tags erfordert — eine häufige Herausforderung, bei der Entwickler Tags erstellen, aber vergessen, sie zu pushen) — ist notwendig für korrektes Release-Tag-Management.

Das Verständnis von **Tags vs. Branches** (ein Tag ist ein fester Zeiger auf einen spezifischen Commit — ein permanentes Label, das sich nicht bewegt — während ein Branch ein bewegbarer Zeiger ist, der mit der Entwicklung voranschreitet) verdeutlicht ihre unterschiedlichen Rollen: Tags zur permanenten Markierung von Releases/Meilensteinen, Branches für laufende Arbeit.

Das Verständnis der Verbindung zu **Semantic Versioning** (MAJOR.MINOR.PATCH-Konventionen zur Kommunikation der Art von Änderungen) und wie Plattformen **Releases** aus Tags erstellen (mit Release Notes und Artefakten zur Verteilung) spiegelt wider, wie Tags in echtes Release-Management passen.

Da das Veröffentlichen und Versionieren von Software ein häufiges Erfordernis ist und Tags der Git-Mechanismus zum Markieren und Referenzieren von Release-Versionen sind (zentral für Release-Management und integriert mit Release-Funktionen von Plattformen), ist das Verständnis von Tags und Releases — Annotated vs. Lightweight Tags, das Pushen von Tags, Tags vs. Branches und ihre Rolle bei Versionierung/Releases — wertvoll und praktisch relevantes Git-Wissen für das Management veröffentlichter Software, ein nützlicher Aspekt der professionellen Entwicklung, das mit Versionierungskonventionen und Release-Prozessen verbunden ist.