Tutorial
Ein Release an einen Git-Tag binden
Versionen, die der Realität entsprechen: ein Release planen, an den echten Git-Tag binden und den Inhalt automatisch aus der Commit-Historie füllen.
Zuletzt aktualisiert:
„Was ist eigentlich in v2.3 drin?" ist in den meisten Teams eine Archäologie-Aufgabe. In Zuuna ist ein Release an den echten Git-Tag gebunden, und sein Inhalt kommt aus der Commit-Historie — nicht aus dem Gedächtnis. Releases gehören zum Developer-Plan.
Was du brauchst
- Den Developer-Plan — siehe Preise.
- Ein API-Token und die eingerichtete zuuna-CLI im Repository.
- Ein Repository, in dem Versionen als Git-Tags existieren (oder ab heute existieren sollen).
1. Werkzeuge bereitlegen
Alles läuft über die CLI, die du schon vom Commit-Verknüpfen kennst — dasselbe ./zuuna, dieselbe .git/zuuna.conf.
2. Release planen
./zuuna plan "v2026.08.1" --tag v2026.08.1 --date 2026-08-15Das legt ein geplantes Release an. Der Tag ist der Schlüssel — nicht der Name. Der Name darf „Sommer-Release" heißen; gematcht wird über v2026.08.1.
3. Tag setzen und pushen
git tag -a v2026.08.1 -m "v2026.08.1"
git push origin v2026.08.1Nichts Zuuna-Spezifisches — dein normaler Release-Handgriff.
4. Manifest schicken
./zuuna release --tag v2026.08.1Jetzt passiert der interessante Teil: Die CLI berechnet auf deinem Rechner den Commit-Bereich vom vorherigen Tag bis zu diesem und meldet ihn als Manifest. Warum lokal? Weil nur dein Repository die volle Historie kennt — Zuuna speichert keine Git-Ancestry und kennt nur Commits, die je einen Kartenschlüssel genannt haben. Beim allerersten Release gibst du den Vorgänger mit --prev an.
5. Anschauen, was das Release zeigt
Das Release listet jetzt: die Karten, deren Arbeit im Bereich liegt, die Commits und gemergten Pull Requests — und, ehrlicher als die meisten Werkzeuge, auch die Arbeit, die nie ein Ticket genannt hat. Gerade die will man vor dem Veröffentlichen gesehen haben.
6. Nacharbeiten und veröffentlichen
Karten lassen sich von Hand ergänzen — der Cherry-Pick, der Backport, die Doku-Änderung ohne Commit. Handverlesenes bleibt stehen, auch wenn das Manifest erneut läuft: Ein zweiter Lauf auf ein veröffentlichtes Release repariert die Daten, statt neu zu veröffentlichen — es feuern also auch keine Webhooks doppelt. Dann: veröffentlichen. Abonnenten des RELEASE_PUBLISHED-Webhooks erfahren es sofort.
Wenn es nicht klappt
- „Kein Vorgänger-Tag gefunden." Erstes Release —
--prevmitgeben. - Das Release ist leer. Der Bereich enthält keine Commits mit Kartenschlüsseln, oder der Tag wurde nicht gepusht.
- Ein falscher Tag. Der Tag ist der Match-Schlüssel — Release-Tag und Git-Tag müssen exakt übereinstimmen.
- 401/403. Das Token braucht den Scope
releases:write— er ist bewusst vongit:writegetrennt, weil Veröffentlichen eine andere Tragweite hat als Verknüpfen.
Nächste Schritte
- Deploy-Ziel und Freigabe einrichten — das Release per Klick live schicken.
- Den Code-Graph lesen.
- Git auf dem Board.
Häufige Fragen
Warum berechnet die CLI den Commit-Bereich und nicht der Server?
Weil nur dein Repository die volle Wahrheit kennt. Zuuna speichert keine Git-Ancestry — es kennt nur Commits, die je einen Kartenschlüssel genannt haben. Der Bereich zwischen zwei Tags lässt sich darum nur dort berechnen, wo die Historie liegt: bei dir.
Was ist mit dem allerersten Release?
Ein Bereich braucht einen Vorgänger. Beim ersten Release gibst du ihn mit --prev selbst an — danach findet die CLI den Vorgänger-Tag von allein.
Kann ich das aus GitHub Actions heraus machen?
Ja. Token als Secret, CLI im Workflow-Schritt — das Manifest lässt sich direkt aus der Pipeline schicken, die auch den Tag baut.
Überschreibt der nächste Lauf meine handverlesenen Karten?
Nein. Von Hand hinzugefügte Karten bleiben stehen. Und ein erneuter Lauf auf ein veröffentlichtes Release repariert dessen Daten, statt es erneut zu veröffentlichen — es werden also auch keine Webhooks doppelt gefeuert.
Welcher Plan?
Releases gehören zum Developer-Plan.