Überblick
Kanban mit Git-Integration: Karten, die Git bewegt
Kanban mit Git-Integration statt Handaktualisierung: Commits, Pull Requests, Releases und Deploy-Gates verschieben Karten über deine Regeln, und der Code-Graph zeigt, was live ging. In Zuuna, ab dem Developer-Tarif.
Das Board lügt selten aus böser Absicht. Es lügt, weil sein Stand von Hand gepflegt wird: Die Arbeit ist längst gemergt, aber die Karte hängt noch in „In Arbeit“, weil niemand dran gedacht hat. Kanban mit Git-Integration dreht das um: Nicht der Mensch bedient das Board, das Repository tut es: Commits, Pull Requests, Releases und Deploy-Gates sind der Stand.
Wie die Karte sich selbst bewegt
Der Mechanismus fängt im Commit an: Erwähnst du eine Karten-ID wie ZNA-2001 in der Commit-Nachricht oder im Branch-Namen, verlinkt sich die Arbeit selbst. Auf der Karte erscheint ein Development-Panel mit Branch, Commits, Pull Request und Build-Status; ein Marker auf dem Board zeigt, welche Karten Code haben.
Von da an bewegen Automationen die Karte, die du festlegst: Karte in „In Arbeit“, wenn ein Branch entsteht oder ein Commit landet. Karte ins Review, wenn ein Pull Request offen ist. Karte in „Fertig“, wenn der Pull Request mergt. Der Repository-Webhook meldet es, ohne dass jemand die Maus bewegt. Und wird der Build rot, steht das rot auf der Karte, nicht irgendwo in der CI-Oberfläche.
Releases und Deploy-Gate
Ein Release in Zuuna hängt an einem echten Git-Tag. Es ist fertig, weil der Tag existiert, und nicht, weil jemand eine Zeile grün markiert hat. Das Deploy-Gate kippt erst, wenn deine Pipeline es meldet; freigeben kannst du am Board. Was wann live ging, steht danach auf einer Zeitachse: Release für Release als Band über dem Boardverlauf.
Der Code-Graph: was ohne Ticket live ging
Ein Board aus Git zeigt auch, was nie eine Karte hatte: Der Code-Graph listet offene Branches und jeden Commit, der ohne Karten-ID live gegangen ist. Genau die Lücke, die handgeführte Boards blind lässt, ist hier sichtbar.
Von Hand gepflegt oder aus Git abgeleitet
| Board von Hand | Board aus Git (Zuuna) | |
|---|---|---|
| Karte zieht weiter, weil | jemand drandenkt | der Pull Request mergt |
| Release ist fertig, weil | die Zeile grün markiert wurde | der Git-Tag existiert |
| Build-Status | steht im CI-Tool, wenn man nachschaut | rot, gelb oder grün auf der Karte |
| Im Streitfall | „wollte ich noch eintragen“ | Belege direkt auf der Karte |
| Arbeit für das Board | täglich, von jedem | keine |
Wenn Coding-Agenten die Karten bedienen
In der Agenten-Ära wird aus dem netten Feature der Kern: Ein Coding-Agent liest die Karte über den Zuuna-MCP-Server (mcp-server-zuuna auf npm), baut in deinem Repository mit seinen eigenen Werkzeugen (Claude Code, Cursor, Codex) und wenn der Pull Request mergt, verschiebt eine deiner Regeln die Karte. Niemand zieht Karten für Agenten von Hand. Wie der Kreislauf eingerichtet wird: Zuuna für KI-Agenten. Warum dem Board aus Git dabei niemand anlügt, steht im Blog: Wenn Agenten den Code schreiben, kann das Board nicht lügen.
Einrichtung: ein Skript, jeder Git-Host
In dein Repository kommt ein Skript: Es meldet Commits an Zuuna, mit einem API-Token und ohne OAuth-App oder Bot-Account. Das funktioniert mit jedem Git-Host: GitHub, GitLab, Gitea, auch mit einer Instanz, die nur im Firmennetz erreichbar ist. Die automatische Pull-Request-Verfolgung läuft über den Repository-Webhook; dort ist GitHub am besten unterstützt, weitere Hosts folgen. Schritt für Schritt: Commits automatisch mit Karten verknüpfen und Karten automatisch durch Git bewegen.
Die Git-Integration ist im Developer-Tarif enthalten: 24 € inkl. MwSt. pro Sitz und Monat, für Firmen 20,17 € netto zzgl. MwSt., mit 14-tägiger Testphase ohne Kreditkarte. Code-Graph und Releases gehören dazu.
Live-Demo ansehen: ein echtes Zuuna-Board, das von echten Commits bewegt wird. Wer aus Jira, Trello, Asana oder Excel kommt, nimmt am besten die kostenlose Migration dazu.
Häufige Fragen
Welcher Tarif enthält die Git-Integration?
Der Developer-Tarif: 24 € inkl. MwSt. pro Sitz und Monat (20,17 € netto zzgl. MwSt.), 14 Tage kostenlos testbar ohne Kreditkarte. Code-Graph und Releases sind dort eingeschlossen.
Funktioniert das mit GitHub, GitLab und Gitea?
Das Commit-Hook beziehungsweise die CLI funktioniert mit jedem Git-Host, auch mit einer eigenen Instanz im Firmennetz. Für die automatische Pull-Request-Verfolgung verbindest du den Repository-Webhook; dort ist GitHub am besten unterstützt, weitere Hosts folgen.
Brauche ich eine OAuth-App oder einen Bot-Account?
Nein. Ein API-Token mit den Scopes, die das Skript braucht, reicht, und lässt sich widerrufen, wenn du fertig bist. In die andere Richtung liest Zuuna dein Repository nicht: Es erhält, was das Skript meldet, und fragt nicht im Repo nach.
Verschieben nur gemergte Pull Requests Karten?
Nein, du legst die Regeln fest: Kartenzüge beim Entstehen eines Branchs, bei Commits, bei offenen oder gemergten Pull Requests oder bei rotem Build, als Automationen, die auf Git-Ereignisse hören. Ohne Regel passiert nichts, außer dass die Belege auf der Karte landen.
Kann ein KI-Agent damit arbeiten?
Ja. Über den MCP-Server mcp-server-zuuna (auf npm) liest der Agent Board und Karten und kommentiert sie. Der Code selbst entsteht im Repo mit den Werkzeugen des Agenten. Zuuna schreibt keinen Code und entscheidet nichts. Details auf der Seite Zuuna für KI-Agenten.
Ist das ein Jira-Ersatz?
Für Entwicklerteams, die Board, Git und Releases in einem Werkzeug wollen: ja, das ist der Kern der Vergleichsseite Zuuna vs. Jira. Ein Marketplace-Ökosystem, hunderte Custom-Workflows und Enterprise-Prozesse ersetzt Zuuna nicht.