GitHub mit Slack integrieren (ohne im Lärm zu versinken)
GitHub richtig mit Slack verbinden – offizielle Integration einrichten, Benachrichtigungen nach Label und Branch filtern und Kanäle nützlich halten.
By Ellis Keane · 2026-03-19
Ein Deploy ist gerade fehlgeschlagen. Der Slack-Kanal, über den dein Team koordiniert, ist still – niemand hat die GitHub Actions-Benachrichtigung gesehen, weil sie in #github-notifications gepostet wurde, einem Kanal, den alle vor Wochen stummgeschaltet haben.
Wenn du nachschaust, wie man GitHub mit Slack integriert, ist dieses Szenario wahrscheinlich der Grund. Die Verbindung dauert ein paar Minuten zur Installation (ich habe unsere einmal zwischen zwei Meetings eingerichtet, was im Nachhinein optimistisch war). Sie tatsächlich nützlich zu machen, dauert etwas länger – und genau darum geht es in diesem Tutorial.
Was die offizielle GitHub-Slack-Integration leistet (und was nicht)
GitHubs offizielle Slack-App postet Benachrichtigungen über PRs, Issues, Deployments und Commits in Slack-Kanäle. Du kannst Kanäle für bestimmte Repos abonnieren, nach Event-Typ filtern und einige Aktionen direkt aus Slack heraus ausführen – Issues schließen, neue öffnen und so weiter.
Was sie nicht tut, ist Kontext zu verstehen. Ein Tippfehler in einer README wird genauso behandelt wie ein Produktions-Hotfix. Ein von einem Bot geöffnetes Dependency-Update liegt neben einem kritischen Sicherheits-Patch. Die Integration ist eine Pipe, kein Filter – und Pipes sind nur nützlich, wenn du kontrollierst, was durch sie fließt.
"Die Integration ist eine Pipe, kein Filter – und Pipes sind nur nützlich, wenn du kontrollierst, was durch sie fließt." – Chris Calo
(Die meisten Teams merken das nach etwa einer Woche, wenn #engineering einem Börsenticker für Commits ähnelt, die niemand sehen wollte.)
Die GitHub-App für Slack einrichten
Drei Schritte, und du bist dabei:
- Installiere die GitHub-App in Slack. Gehe zum App-Verzeichnis deines Slack-Workspaces und suche nach „GitHub". Du benötigst Workspace-Admin-Berechtigungen – oder zumindest jemanden, der sie hat und dir einen Gefallen schuldet.
- Authentifiziere dich. Tippe
/github signin in einem beliebigen Kanal. Dadurch wird dein GitHub-Konto verknüpft, sodass Slack reichhaltigere Benachrichtigungen anzeigen und dir ermöglichen kann, mit Issues zu interagieren, ohne die Unterhaltung zu verlassen.
- Abonniere einen Kanal für ein Repo. In dem Kanal, in dem du Benachrichtigungen möchtest:
``` /github subscribe owner/repo-name ``` Standardmäßig abonnierst du issues, pulls, commits, releases und deployments – fünf Event-Typen, mehr als die meisten Kanäle benötigen.
- Kürze sofort. Kündige das Abonnement für das, was dem Kanal nicht dient:
``` /github unsubscribe owner/repo-name commits ``` Für die meisten Engineering-Teams sind pulls und deployments die Abonnements, die es wert sind, beizubehalten. issues hängt davon ab, ob dein Team in GitHub triagiert oder einen separaten Tracker wie Linear verwendet. commits ist fast immer Rauschen – wenn du Code-Änderungen sehen möchtest, schau dir den PR an.
Die vollständige Befehlsreferenz findest du in den Integration-Repo-Docs.
Erst abonnieren, dann sofort die Event-Typen abbestellen, die dem Kanal nicht nützen. Das Standard-„Alles"-Abonnement ist der Grund, warum die meisten Teams den Kanal irgendwann ganz stummschalten.
GitHub-Benachrichtigungen in Slack, die wirklich helfen
Hier hören die meisten Tutorials auf – und hier werden die meisten Integrationen still nutzlos. Das Subscribe/Unsubscribe-System ist grob: entweder alle PRs oder keine PRs, alle Issues oder keine Issues. Wenn du ein Monorepo mit vierzig Mitwirkenden hast, ist „alle PRs" ein Feuerwehrschlauch.
Label-basiertes Filtern ist die Lösung, die kaum genutzt wird. Du kannst Benachrichtigungen nach Label filtern:
``` /github subscribe owner/repo-name +label:"needs-review" ```
Jetzt sieht der Kanal nur PRs oder Issues mit dem Tag needs-review. Für Teams, die Labels konsequent nutzen (und das ist ein echtes Commitment, keine Kleinigkeit), verwandelt das die Integration von laut zu nützlich. PRs, die Aufmerksamkeit benötigen, tauchen in Slack auf. Alles andere bleibt in GitHub, wo es hingehört.
Workflow-Run-Filtering ermöglicht es dir, CI-Benachrichtigungen nach Branch einzugrenzen:
``` /github subscribe owner/repo-name workflows +branch:main ```
Das bedeutet, du siehst nur Workflow-Runs, die auf main ausgelöst wurden – nicht jeden CI-Lauf eines Feature-Branches. Wenn dein Team GitHub Actions für Deployments nutzt, so erhältst du produktionsrelevante Alerts ohne den konstanten Strom grüner Häkchen von Entwicklungsbranches.
Kanal-Architektur ist entscheidend. Ein einziger #github-Kanal für alles ist ein Rezept für Stummschalten. Erwäge eine Aufteilung:
| Kanal | Abonnements | |-------|-------------| | #deploys | Nur deployments | | #pr-reviews | pulls +label:"needs-review" | | #incidents | issues +label:"P0" |
Drei fokussierte Kanäle schlagen einen lauten. Jeder hat einen klaren Zweck, und Teammitglieder können den für ihre Rolle relevanten beitreten. (Ich weiß, das klingt offensichtlich, aber ich habe Teams mit einem einzigen #dev-Kanal gesehen, der Slack-Bots, GitHub-Benachrichtigungen, Deployment-Alerts und allgemeinen Chat abwickelt. Das ist Chaos.)
Drei Workflows, die konfiguriert werden sollten
Geplante Erinnerungen für veraltete PRs. GitHubs geplante Erinnerungen liefern Hinweise an Slack, wenn PRs auf Review warten. Du konfigurierst es über GitHubs Web-UI (Einstellungen, dann Geplante Erinnerungen), nicht über einen Slack-Befehl. Es erfasst die PRs, die still im Backlog veralten, weil niemand sie bemerkt hat.
Deploy-Preview-Links. Wenn ein PR eine Deployment-Vorschau auslöst (Vercel, Netlify oder Ähnliches), erscheint der Status in der Slack-Benachrichtigung. Dein Designer kann die Vorschau-URL direkt aufrufen, ohne GitHub zu öffnen – ein Kontextwechsel weniger pro Review.
Thread-basierte Gespräche. Kommentare zu einer PR-Benachrichtigung bleiben in einem Slack-Thread. Dein „Sieht gut aus, eine Kleinigkeit in Zeile 47" passiert dort, wo der Rest des Kontexts lebt. Der Kommentar synchronisiert nicht zurück zu GitHub (nur Slack), was sowohl eine Einschränkung als auch – man könnte sagen – ein Feature ist.
Wenn die native Integration an ihre Grenzen stößt
Die offizielle Integration deckt viel ab, aber es gibt Muster, die sie nicht bewältigen kann:
Repo-übergreifende Sichtbarkeit. Wenn dein Projekt drei Repos umfasst, brauchst du drei separate Abonnements mit drei separaten Filterkonfigurationen. Es gibt kein „Zeige mir alles zu Projekt X über Repos hinweg". Du pflegst parallele Konfigurationen und hoffst, dass sie konsistent bleiben.
GitHub mit deinem Issue-Tracker verbinden. Wenn dein Team Linear als zentrale Quelle für Aufgaben nutzt, weiß die GitHub-Slack-Integration nichts von dieser Beziehung. Ein PR könnte ein Linear-Issue schließen, aber Slack weiß es nicht – die Benachrichtigung sagt „PR gemergt" ohne Kontext darüber, für welche Aufgabe es war oder wer darauf wartete.
Label-Disziplin im großen Maßstab. Label-basiertes Filtern funktioniert, erfordert aber Konsequenz – jemand muss Labels anwenden, und der Filter bricht in dem Moment, in dem ein PR ohne Label ausgeliefert wird. Der Wartungsaufwand wächst mit dem Team. Irgendwann verbringst du mehr Zeit damit, Filter aktuell zu halten, als du durch sie sparst.
(Das ist der Punkt, an dem Teams zu Zapier oder einem Custom-Bot greifen, was funktioniert – bis die Webhook-Auth veraltet, das Rate-Limit greift oder jemand das Unternehmen verlässt und niemand mehr weiß, wie es verdrahtet ist.)
Dauerhaft nützlich halten
Die GitHub-Slack-Integration ist eines jener Tools, das entweder unsichtbar ist (weil es gut konfiguriert ist) oder aktiv gehasst wird (weil es das nicht ist). Der Unterschied liegt in der Einrichtung:
- Abonniere nur die Event-Typen, die dem Zweck des Kanals dienen
- Nutze Label- und Branch-Filter, um Rauschen zu reduzieren, bevor es Slack erreicht
- Verteile Benachrichtigungen auf fokussierte Kanäle statt auf einen Sammelkanal
- Richte geplante Erinnerungen für veraltete PRs über GitHubs Web-UI ein
- Akzeptiere, dass die native Integration Grenzen hat – und wenn repo-übergreifender Kontext oder Verbindungen zum Issue-Tracker wichtig sind, schaue dir Tools an, die für diese Ebene entwickelt wurden
Wenn du GitHub mit Slack integrieren möchtest, ist die native App der richtige Ausgangspunkt. Die oben genannten Tipps zu Filtern und Kanal-Architektur halten sie über die erste Woche hinaus nützlich. Und wenn du über das hinausgewachsen bist, was eine Benachrichtigungs-Pipe leisten kann – wenn das fehlende Stück die Beziehung zwischen einem PR, dem Linear-Ticket, zu dem er gehört, und dem Slack-Thread ist, in dem der Ansatz diskutiert wurde – dann ist das, wofür wir Sugarbug bauen.
Verbinde GitHub, Linear, Slack und Figma in einem Wissensgraph – sodass jeder PR mit der Unterhaltung und dem Ticket verknüpft ist, zu dem er gehört.
Q: Wie integriere ich GitHub mit Slack? A: Installiere die GitHub-App aus dem Slack-App-Verzeichnis, authentifiziere dich mit /github signin und abonniere dann Kanäle für Repos mit /github subscribe owner/repo-name. Kürze die Event-Typen sofort – die Standardeinstellungen umfassen alles, was fast immer zu laut ist.
Q: Kann Sugarbug die GitHub-Slack-Integration ersetzen? A: Sugarbug arbeitet parallel dazu, anstatt sie zu ersetzen. Die native Integration verarbeitet Benachrichtigungen; Sugarbug erstellt einen Wissensgraph, der GitHub-PRs mit den entsprechenden Linear-Issues, Slack-Diskussionen und Figma-Designs verknüpft – sodass du den vollständigen Kontext einer Änderung siehst, nicht nur, dass ein PR gemergt wurde.
Q: Wie filtere ich GitHub-Benachrichtigungen in Slack nach Label? A: Verwende den Label-Filter beim Abonnieren: /github subscribe owner/repo-name +label:"needs-review". Nur Elemente mit diesem Label werden im Kanal gepostet. Du kannst mehrere Label-Filter kombinieren und sie mit Event-Typ-Abonnements mischen.
Q: Verfolgt Sugarbug GitHub-Aktivitäten automatisch in Slack und Linear? A: Ja. Sugarbug verbindet sich über eine API mit GitHub, Slack und Linear und korreliert Aktivitäten – wenn ein GitHub-PR auf eine Slack-Unterhaltung verweist oder ein Linear-Ticket schließt, werden diese Verbindungen im Wissensgraph nachverfolgt, ohne manuelles Tagging oder Label-Disziplin.