EMZETT.
Login

Emzett Wiki

Git-Tags, Releases und Changelog: Versionen sauber veröffentlichen

Properties1
tagsglossar, git, release

2 Min. Lesezeit

Git-Tags, Releases und Changelog: Versionen sauber veröffentlichen

Kurz: Tags markieren bestimmte Commits als Version, Releases bündeln sie mit Erklärungen und Dateien, und ein Changelog beschreibt für Nutzer, was sich geändert hat.

Genauer: Eine Software-Version ist ein eindeutig benannter Stand des Codes. Dafür nutzt man Git-Tags, Versionsnummern (SemVer) und Veröffentlichungsnotizen.

Im Detail

Tags

git tag v1.4.0                       # leichtgewichtiger Tag
git tag -a v1.4.0 -m "Version 1.4.0" # annotierter Tag (mit Autor, Datum, Nachricht)
git push origin v1.4.0               # Tag veröffentlichen (Tags werden nicht automatisch gepusht)
git tag -l 'v1.*'                    # Tags auflisten
git checkout v1.4.0                  # diesen Stand ansehen
git tag -d v1.4.0                    # lokal löschen

Tags sind unveränderliche Marken (nicht verschieben, nachdem sie veröffentlicht wurden). Für Releases nutzt man annotierte (und ggf. signierte, -s) Tags.

Versionsnummern

Semantic Versioning: MAJOR.MINOR.PATCH (zum Beispiel 2.3.1): MAJOR bei inkompatiblen Änderungen, MINOR bei neuen, kompatiblen Funktionen, PATCH bei Fehlerbehebungen. Vorabversionen: 2.0.0-beta.1. Alternative CalVer (2026.03). Die Nummer steht in Tag, Paketdatei (package.json, pyproject.toml) und Release.

Releases und Changelog

Auf GitHub/GitLab erzeugt ein Release aus einem Tag eine Seite mit Beschreibung, Download-Dateien (Artefakte) und automatisch generierten Notizen. Ein CHANGELOG.md (Format „Keep a Changelog“) gliedert nach Version in Added, Changed, Deprecated, Removed, Fixed, Security und richtet sich an Nutzer, nicht an Entwickler (nicht einfach die Commit-Liste einfügen). Mit Conventional Commits und Werkzeugen (release-please, semantic-release, changesets) lassen sich Versionen und Changelog automatisch erzeugen.

Ablauf und Tipps

  1. Tests grün, Version erhöhen, Changelog ergänzen.
  2. Commit, Tag setzen, pushen.
  3. CI baut Artefakte (Pakete, Container-Images) und veröffentlicht (npm, PyPI, Docker Registry), idealerweise reproduzierbar und signiert.
  4. Release-Notizen schreiben, Breaking Changes deutlich hervorheben und Migrationshinweise geben.
  5. Bei Fehlern neue Patch-Version statt Tag zu verschieben. Für Websites reichen oft Deployments pro Commit; Tags/Releases sind wichtig bei Bibliotheken, Apps und Tools, die andere installieren.

Siehe auch: Semantic Versioning, Conventional Commits, CI/CD-Pipeline, README-Datei

Backlinks