Kanban mit Git-Integration: Git auf dem Board

Tracker und Code driften auseinander: Der Status auf dem Board stimmt selten mit dem echten Stand im Repository überein. Git auf dem Board schließt die Lücke: automatisch.

So funktioniert es

Erwähne eine Karten-ID im Commit oder Branch-Namen: die Arbeit verlinkt sich 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.

Einrichtung in einer Minute

Leg ein Skript in dein Repository. Fertig. Es funktioniert mit jedem Git-Host. Alternativ verbindest du den Repository-Webhook, damit Pull Requests über deine Regeln Karten automatisch verschieben.

Build- & Test-Status auf der Karte

Melde deine CI-Ergebnisse auf die Karte und lies rot, gelb oder grün auf einen Blick (ohne die Pipeline zu öffnen).

Git-gesteuerte Automationen

Lass das Board auf deinen Code reagieren: Karte verschieben, wenn ein Branch entsteht, ein Commit landet, ein Pull Request mergt oder der Build rot wird.

Teil von Projektmanagement für Entwickler. Siehe auch Der Code-Graph und Zuuna vs. Jira.

Anleitungen

• Commits automatisch mit Karten verknüpfen (der post-commit-Hook in fünf Minuten).
• GitHub Pull Requests mit dem Board verbinden.
• Build- und Test-Status auf der Karte anzeigen.
• Karten automatisch durch Git bewegen.
• API-Token erstellen und die erste Abfrage schicken.

Die Referenz dazu

Wie das technisch läuft, steht offen in der CLI-Referenz (inklusive der Regel, wann eine Karten-ID Arbeit bedeutet und wann nur einen Verweis). Wer es selbst bauen will, nimmt die REST-API oder Webhooks.

Das Repository anbinden

Wie die Verbindung konkret entsteht, steht pro Anbieter: GitHub als App-Installation, Gitea auch für eine Instanz, die nur im Firmennetz erreichbar ist.