Tutorial
Karten automatisch durch Git bewegen
Regeln bauen, die Karten aus Git heraus bewegen: Branch angelegt heißt In Arbeit, Pull Request gemerged heißt Review, roter Build heißt zurück.
Zuletzt aktualisiert:
Die vorigen Tutorials haben Git und Board verbunden. Jetzt kommt der Teil, der Zeit spart: Regeln, die Karten aus Git heraus bewegen, damit niemand mehr eine Karte von Hand nachzieht, weil der Code längst gemerged ist. Git-Trigger brauchen den Developer-Plan; Automatisierungen als Funktion gibt es ab Private Plus.
Was du brauchst
- Den Developer-Plan für die Git-Auslöser — siehe Preise.
- Eingerichtetes Git: Commits verknüpfen und, für PR-Regeln, den GitHub-Webhook.
- Ein Board mit einer Arbeits- und einer Review-Spalte.
1. Voraussetzungen prüfen
Ohne verknüpfte Git-Ereignisse haben die Regeln nichts, worauf sie hören könnten. Richte zuerst den Hook ein — die Regeln bauen darauf auf.
2. Regel bauen: Branch angelegt → In Arbeit
Die nützlichste Regel des Satzes, weil sie einen Handgriff ersetzt, den alle vergessen:
- Wenn ein Branch angelegt wird,
- dann verschiebe die Karte in „In Arbeit“.
Ein Branch-Ereignis wertet den Branch-Namen aus, also reicht hier feature/zna164-sprint-picker — anders als beim Pull Request.
3. Regel bauen: Pull Request gemerged → Review
- Wenn ein Pull Request gemerged wird,
- dann verschiebe die Karte nach „Review“ und benachrichtige die zuständige Person.
Hier lohnt eine bewusste Entscheidung: direkt auf „Erledigt“ zu verschieben ist verlockend, überspringt aber die Kontrolle. Wer ein Review im Prozess hat, lässt den letzten Schritt bei einem Menschen.
4. Regel bauen: Build rot → zurück und kommentieren
- Wenn CI fehlschlägt,
- dann verschiebe die Karte zurück nach „In Arbeit“ und schreibe einen Kommentar („Build fehlgeschlagen — bitte ansehen“).
Der Kommentar ist wichtiger als die Verschiebung: Er hinterlässt eine Spur, warum die Karte zurückgewandert ist. Eine Karte, die sich ohne Erklärung bewegt, verunsichert mehr, als sie hilft.
5. Bedingungen einschränken
Ohne Bedingung feuert eine Regel auf jeder Karte des Boards. Grenze ein, was zusammengehört: nur Karten in bestimmten Spalten, nur ab einer Priorität, nur mit einem bestimmten Epic. Regeln, die zu oft laufen, werden abgeschaltet — und dann fehlen auch die nützlichen.
6. Testen und die Lauf-Historie lesen
Jede Regel einmal echt auslösen: Branch anlegen, Test-PR mergen, Build absichtlich rot machen. In der Lauf-Historie steht danach, ob die Regel griff. Drei Ausgänge sind möglich — erfolgreich, fehlgeschlagen, übersprungen. „Übersprungen“ heißt, eine Bedingung traf nicht zu, und zählt nicht gegen dein Kontingent.
Wenn es nicht klappt
- Merge bewegt nichts. Kartenschlüssel stand nur im Branch-Namen statt im PR-Titel — oder der PR wurde geschlossen statt gemerged.
- Branch-Regel greift nicht. Kein Kartenschlüssel im Branch-Namen, oder ein falsches Präfix.
- Karten springen hin und her. Zwei Regeln arbeiten gegeneinander — meistens eine Rückwärts-Regel ohne Bedingung. Grenze auf die Zielspalte ein.
- Kontingent aufgebraucht. Erfolgreiche und fehlgeschlagene Läufe zählen. Laute Regeln aufräumen oder Plan wechseln.
Nächste Schritte
- Board-Automatisierungen einrichten — die Grundlagen ohne Git.
- Build- und Test-Status auf der Karte anzeigen.
- Projektmanagement für Entwickler.
Häufige Fragen
Welche Git-Ereignisse gibt es als Auslöser?
Branch angelegt, Commit gepusht, Pull Request geöffnet, Pull Request gemerged, CI grün und CI rot. Dazu Release veröffentlicht, wenn du mit Releases arbeitest.
Kann ich eine Karte automatisch auf Erledigt setzen?
Technisch ja — eine Regel auf „Pull Request gemerged“ kann direkt in die Erledigt-Spalte verschieben. Ob das eine gute Idee ist, hängt an deinem Prozess: Wer noch ein Review dazwischen hat, sollte auf Review verschieben und den letzten Schritt beim Menschen lassen.
Was passiert bei einem Downgrade des Plans?
Bestehende Regeln laufen weiter. Der Plan entscheidet, ob du neue anlegen kannst und wie viele Läufe im Monat enthalten sind — er schaltet vorhandene Regeln nicht ab.
Wie viele Läufe sind enthalten?
Private Plus 200 pro Monat, Business Standard 1.000, Business Pro 25.000. Erfolgreiche und fehlgeschlagene Läufe zählen; übersprungene nicht.
Warum bewegt sich die Karte beim Merge nicht?
Zwei häufige Gründe: Der Kartenschlüssel stand nur im Branch-Namen statt im PR-Titel, oder der Pull Request wurde geschlossen statt gemerged — ein Schließen ohne Merge löst absichtlich nichts aus.