Tutorial
GitHub Pull Requests mit dem Board verbinden
Einen Repository-Webhook einrichten, damit Pull Requests auf der Karte erscheinen — mit den zwei Fallen, an denen es sonst stillschweigend scheitert.
Zuletzt aktualisiert:
Commits zeigen, woran gearbeitet wurde. Pull Requests zeigen, was zur Übernahme ansteht — und wann es tatsächlich gelandet ist. Diese Anleitung verbindet beides mit dem Board. Die Git-Integration gehört zum Developer-Plan, und Pull-Request-Tracking läuft heute nur über GitHub.
Was du brauchst
- Den Developer-Plan — siehe Preise.
- Ein GitHub-Repository, in dem du Administrator bist (Webhooks anlegen setzt das voraus).
- Am besten vorher: Commits mit Karten verknüpfen.
1. Plan prüfen
Ohne Developer-Plan nimmt der Endpunkt keine Ereignisse an. Der Webhook wäre eingerichtet, aber jede Zustellung liefe ins Leere.
2. Webhook-URL und Secret in Zuuna holen
Zuuna stellt pro Repository eine Webhook-URL und ein dazugehöriges Secret bereit. Beides kopierst du dir — das Secret ist der einzige Beweis gegenüber Zuuna, dass eine Zustellung wirklich von GitHub stammt.
3. Webhook in GitHub eintragen
Im Repository: Settings → Webhooks → Add webhook.
- Payload URL — die URL aus Zuuna.
- Content type —
application/json. Die Voreinstellung ist eine andere; stell sie um, sonst kommt der Inhalt in einem Format an, das nicht ausgewertet wird. - Secret — das Secret aus Zuuna.
- Events — „Let me select individual events“, dann Pull requests und Pushes.
4. Ping prüfen
GitHub schickt sofort einen Ping. Unter „Recent Deliveries“ steht das Ergebnis. Der grüne Haken ist die eigentliche Bestätigung, dass das Secret stimmt — kommt dort ein Fehler, ist fast immer das Secret falsch kopiert oder der Content type noch nicht auf JSON gestellt.
5. Kartenschlüssel in den PR-Titel schreiben
Und hier ist die Falle, die den meisten Leuten eine halbe Stunde kostet:
Ein Kartenschlüssel, der nur im Branch-Namen oder nur in der PR-Nummer steht, trifft nichts. Die Antwort lautet dann „0 verknüpft“, und keine Karte bewegt sich.
Der Grund: Bei einem Pull-Request-Ereignis wertet Zuuna Titel und Beschreibung aus, nicht die Referenz. Schreib den Schlüssel also in den PR-Titel — ZNA-164: Sprint-Auswahl im Backlog — oder in die Beschreibung. Ein guter Branch-Name schadet nicht, er reicht hier nur nicht.
6. Mergen und die Karte prüfen
Beim Öffnen des Pull Requests erscheint er auf der Karte; beim Mergen wechselt sein Zustand, und die passenden Automatisierungen laufen. Wird ein Pull Request dagegen ohne Merge geschlossen, passiert bewusst nichts: Verworfene Arbeit soll keine Karte weiterschieben.
Wenn es nicht klappt
- Zustellung rot in GitHub. Secret oder URL stimmen nicht. In GitHub bearbeiten, Secret neu einfügen, „Redeliver“ klicken.
- Zustellung grün, aber nichts auf der Karte. Der Schlüssel stand nur im Branch-Namen oder in der PR-Nummer. In den Titel schreiben.
- Merge bewegt die Karte nicht. Prüf, ob überhaupt eine Regel auf „Pull Request gemerged“ hört — die Verknüpfung allein bewegt nichts, das macht die Automatisierung.
- Push-Ereignisse fehlen. Beim Webhook ist nur „Pull requests“ ausgewählt. Beide Ereignisse aktivieren.
Nächste Schritte
- Karten automatisch durch Git bewegen — was beim Merge passieren soll.
- Build- und Test-Status auf der Karte anzeigen.
- Zuuna vs. Jira — wie sich das von der Atlassian-Variante unterscheidet.
Häufige Fragen
Warum bewegt sich meine Karte nicht?
Fast immer, weil der Kartenschlüssel nur im Branch-Namen oder in der PR-Nummer steht. Ein Pull-Request-Ereignis wertet diese Felder nicht aus — schreib den Schlüssel in den PR-Titel oder in die Beschreibung.
Brauche ich eine GitHub-App oder OAuth?
Nein. Es genügen die Webhook-URL und das Secret, die du in GitHub einträgst. Mehr Rechte gibt dein Repository dabei nicht her.
Funktioniert das auch mit GitLab oder Bitbucket?
Für Pull Requests heute nicht — dieser Weg ist GitHub-spezifisch. Commits und Branches funktionieren dagegen über den post-commit-Hook mit jedem Git-Host.
Ist der Endpunkt sicher, obwohl er öffentlich erreichbar ist?
Ja. GitHub signiert jede Zustellung mit dem gemeinsamen Secret, und Zuuna prüft diese Signatur über den unveränderten Rohtext der Anfrage. Ohne gültige Signatur wird nichts verarbeitet.
Was passiert, wenn ein Pull Request ohne Merge geschlossen wird?
Nichts — und das ist Absicht. Verworfene Arbeit soll keine Karte in „In Arbeit“ schieben und dort einen Fortschritt vortäuschen, den es nicht gab.