GitHub verbinden | kanman Dokumentation

GitHub ist die umfassendste Integration von kanman. Eine Verbindung deckt beide Seiten der Arbeit ab: GitHub Issues als Tracker und das Repository, in dem kanman Pull Requests öffnet und auf Ihre CI wartet.

Was kanman mit GitHub tut

Bereich	Was passiert
Issues	kanman spiegelt die Issues des Tracker-Repositorys, die das Übernahme-Label tragen (standardmäßig `kanman`). Freigegebene Stories aus der Aufnahme werden als Issues mit diesem Label angelegt. Nachweispakete erscheinen als Issue-Kommentare.
Aufgreifen	Ein Issue wird aufgegriffen, wenn es das Übernahme-Label hat und im Status mit der Rolle Ready liegt.
Branches	Jeder Run arbeitet auf einem eigenen Branch, zum Beispiel `kanman/sbx-12-export-invoices`. Akzeptanz-Specs liegen auf einem Branch `kanman/spec/<KEY>`.
Pull Requests	Ein Pull Request pro Story gegen einen Branch, den Ihr Team erlaubt hat, mit dem Nachweispaket als Kommentar.
CI	kanman liest Check Runs und Commit-Status. Eine grüne CI ist Teil des Outcome-Gates. Zusätzlich setzt kanman einen eigenen Commit-Status `kanman/outcome-gate`.

kanman löscht keine Repositories, keine Branches, die es nicht selbst angelegt hat, und keine Issues.

Verbinden

Sie brauchen Admin-Rechte im Workspace.

Öffnen Sie in kanman Einstellungen > Git (dorthin führt auch die Schaltfläche GitHub oder GitLab verbinden im Schritt Tracker der Team-Einrichtung).
Klicken Sie auf der GitHub-Karte auf Verbinden. GitHub öffnet sich.
Prüfen Sie den angefragten Zugriff und klicken Sie auf Authorize. Schränkt Ihre Organisation den Zugriff von Drittanbietern ein, muss eine Organisations-Ownerin oder ein Owner kanman für die Organisation freigeben.
GitHub leitet Sie zu kanman zurück, und die Karte zeigt “Verbunden als” mit Ihrem GitHub-Benutzernamen.

Die Verbindung nutzt Ihr GitHub-Konto. kanman erreicht die Repositories, die dieses Konto erreicht; in kanman schränken Sie das pro Team auf die Repositories in den Team-Einstellungen ein.

Tipp

Verbinden Sie ein Konto, das nur Zugriff auf die Repositories hat, die Ihre Teams brauchen, zum Beispiel einen eigenen Maschinen-Benutzer. Ein Zugriff, den das Konto nie hat, kann auch nicht missbraucht werden.

Berechtigungen

GitHub zeigt die angefragten Scopes, bevor Sie bestätigen. kanman fragt nach:

Scope	Wozu
`repo`	Repositories klonen, den Branch des Runs pushen, Issues spiegeln und anlegen, Pull Requests öffnen und kommentieren, Checks und Commit-Status lesen
`workflow`	Branches in Repositories pushen, die GitHub-Actions-Workflows enthalten
`read:user`	Anzeigen, welches Konto verbunden ist

Runs klonen und pushen mit dem Token der Verbindung. Es wird git als Header übergeben, nie in URLs geschrieben und aus Logs entfernt. Siehe Sandbox und Secrets.

Kommt in einem späteren Release

Eine GitHub App mit kurzlebigen Tokens pro Repository für jeden Run.

Branch-Schutz und Reviews

Ihre Regeln gelten für kanman genauso wie für alle anderen. Verlangt main ein zustimmendes Review und grüne Checks, braucht ein Pull Request von kanman dasselbe. kanmans eigene Merge-Richtlinie kann nur Einschränkungen hinzufügen, nie die von GitHub umgehen.

Wir empfehlen:

Lassen Sie den Branch-Schutz auf den Branches aktiv, die kanman ansteuert.
Machen Sie kanman/outcome-gate zum verpflichtenden Status-Check. Dann lässt sich ein Pull Request, dessen Outcome-Gate nicht bestanden ist, auch in GitHub nicht mergen.
Nutzen Sie eine CODEOWNERS-Datei, wenn bestimmte Bereiche bestimmte Reviewer brauchen.
Lassen Sie die CI verpflichtend. kanman wartet ohnehin darauf, und verpflichtende Checks machen das Ergebnis auch in GitHub sichtbar.

Labels und Status

Das Übernahme-Label legen Sie in den Team-Einstellungen unter Tracker fest (Übernahme-Label). Es wird im Repository angelegt, wenn kanman es zum ersten Mal verwendet.
GitHub Issues haben kein Statusfeld. kanman nutzt pro zugeordnetem Status ein Label, zum Beispiel Ready oder In Progress. Wenn Sie eine Karte in kanman verschieben, tauscht kanman das Status-Label; Done schließt das Issue. Ein geschlossenes Issue ohne Status-Label gilt als Done.
Änderungen in GitHub erreichen kanman innerhalb weniger Minuten. Jetzt synchronisieren in den Tracker-Einstellungen des Teams holt sie sofort, und Übernahme ansehen zeigt, welche Issues kanman gerade aufgreifen würde.

Trennen

Öffnen Sie Einstellungen > Git und klicken Sie auf der GitHub-Karte auf Trennen. Um kanmans Zugriff auch auf GitHub-Seite zu entfernen, widerrufen Sie ihn in GitHub unter Settings > Applications > Authorized OAuth Apps. Teams, die diese Verbindung nutzen, können nicht synchronisieren und keine Runs ausführen, bis Sie wieder verbinden. Bestehende Issues, Branches und Pull Requests bleiben in GitHub.

Fehlerbehebung

Symptom	Wahrscheinliche Ursache
Ein Repository lässt sich nicht nutzen	Das verbundene GitHub-Konto hat keinen Zugriff darauf, oder Ihre Organisation hat kanman nicht freigegeben.
Stories werden nicht in den Tracker geschrieben	Issues sind im Repository ausgeschaltet (häufig bei Forks). Schalten Sie sie unter Settings > General > Features ein.
Ein Issue wird nicht aufgegriffen	Ihm fehlt das Übernahme-Label, oder sein Status-Label ist nicht der Rolle Ready zugeordnet. Prüfen Sie Übernahme ansehen in den Tracker-Einstellungen des Teams.
Ein Run wartet endlos auf die CI	Auf dem Branch des Runs läuft kein Workflow. Prüfen Sie die `on:`-Trigger Ihrer Workflows; sie sollten `pull_request` enthalten.
kanman kann nicht pushen	Branch-Schutzregeln gelten für alle Branches, auch `kanman/`. Erlauben Sie Pushes auf `kanman/` oder nehmen Sie sie von der Regel aus.