Schluss mit dem Wechseln zwischen Linear und GitHub
Warum Entwickler Stunden beim Wechseln zwischen Linear und GitHub verlieren, was die native Integration leistet und wie beide Tools als eines arbeiten.
By Ellis Keane · 2026-03-17
Der Branch-Name lautete feat/onboarding-email-verification. Das Linear-Ticket sagte: „E-Mail-Verifizierungsflow implementieren – Priorität: dringend." Der GitHub-PR hatte drei Review-Kommentare, zwei davon ungelöst. Und irgendwo in einem Slack-Thread vom letzten Dienstag hatte unsere Designerin darauf hingewiesen, dass der Text der Bestätigungs-E-Mail vor dem Launch aktualisiert werden musste.
Ich wusste, dass all das existierte. Ich wusste nur nicht, dass es alles zum selben Arbeitsvorgang gehörte – bis ich zwanzig Minuten damit verbracht hatte, zwischen Linear, GitHub, Slack und meinem eigenen immer unzuverlässigeren Gedächtnis zu tabben.
Wenn Sie jemals in einem Team gearbeitet haben, das sowohl Linear als auch GitHub verwendet (was inzwischen auf so gut wie jedes Engineering-Team zutrifft, das entschieden hat, dass Jira eher eine Strafe als ein Werkzeug ist), wissen Sie genau, wovon ich rede. Das ständige Wechseln zwischen Linear und GitHub ist kein kleines Ärgernis – es ist eine echte Steuer auf Ihre Fähigkeit, gleichzeitig zu verstehen, was in Ihrer Codebasis und Ihrem Projektplan tatsächlich passiert.
Der Mythos: Diese Tools kommunizieren miteinander
Linear hat eine GitHub-Integration. Es ist eine der ersten Dinge, die Sie einrichten. Und es funktioniert – auf eine spezifische, begrenzte Art, die es sich lohnt zu verstehen, denn die Lücke zwischen dem, was die Leute glauben, was sie tut, und dem, was sie tatsächlich tut, ist der Ort, an dem der größte Schmerz sitzt.
Das handhabt die GitHub-Integration von Linear tatsächlich: Wenn Sie einen Branch aus einem Linear-Issue erstellen, enthält der Branch-Name die Issue-ID. Wenn ein PR, der auf diese Issue-ID verweist, gemergt wird, kann Linear das Issue automatisch auf „Erledigt" setzen. Sie können PR-Links auf der Linear-Issue-Detailseite sehen. Das ist wirklich nützlich, und ich möchte es nicht kleinreden.
Das handhabt sie nicht: Kommentare zwischen den beiden Plattformen synchronisieren. Darauf hinweisen, wenn ein PR ungelöste Review-Kommentare hat, das Linear-Ticket aber auf „Erledigt" gesetzt wurde. Die Slack-Diskussion, in der der Ansatz debattiert wurde, mit dem Issue oder dem PR verbinden. Anzeigen, dass die Figma-Designs nach dem Öffnen des PRs aktualisiert wurden. Wissen, dass die Anforderung hinter diesem Ticket letzte Woche still in einem Notion-Dokument zurückgestellt wurde.
Die Integration verwaltet den mechanischen Link – Issue zu PR. Sie verwaltet nicht das kontextuelle Netz um beide herum. Und dieses kontextuelle Netz ist genau das, was Sie jedes Mal rekonstruieren, wenn Sie zwischen Linear und GitHub wechseln.
Was beim Kontextwechsel tatsächlich passiert
Lassen Sie mich durchgehen, wie ein typischer Kontextwechsel zwischen Linear und GitHub tatsächlich aussieht, weil ich denke, dass die Leute den kognitiven Aufwand unterschätzen.
Sie sind in Linear. Sie sehen ein Ticket mit dem Status „In Review". Sie möchten den Stand des Reviews wissen, also klicken Sie sich zum PR auf GitHub durch. Jetzt lesen Sie Review-Kommentare, aber Sie haben den Kontext des Linear-Tickets verloren – die Priorität, die Abnahmekriterien, die verknüpften Sub-Tasks. Sie tabben zurück zu Linear. Jetzt haben Sie Ihren Platz in den Review-Kommentaren verloren. Sie tabben zurück zu GitHub. Ein Reviewer hat etwas aus einer Slack-Konversation erwähnt, also öffnen Sie Slack und suchen nach dem Thread. Zwanzig Minuten sind vergangen (ich weiß es, weil ich mich selbst dabei gestoppt habe), und Sie haben immer noch kein vollständiges Bild davon, ob dieses Ticket wirklich versandbereit ist.
Das Problem ist nicht, dass ein einzelnes Tool schlecht ist. Linear ist hervorragend in dem, was es tut. GitHub ist hervorragend in dem, was es tut. Das Problem ist, dass „was es tut" an der Grenze jedes Tools aufhört, und die Arbeit, die Sie zu verstehen versuchen, diese Grenzen nicht respektiert.
Das Wechseln zwischen Linear und GitHub ist nicht nur ein Tab-Management-Problem. Es ist ein Problem der Kontextrekonstruktion – jeder Wechsel zwingt Sie, das mentale Modell der Arbeit aus der Perspektive eines anderen Tools neu aufzubauen.
Warum „Einfach alles verknüpfen" nicht skaliert
Der Standardrat hier ist, beim Verknüpfen diszipliniert zu sein. Jede PR-Beschreibung sollte die Linear-Ticket-URL enthalten. Jedes Linear-Ticket sollte auf seinen PR verlinken. Jede Commit-Message sollte das Issue referenzieren.
Und das funktioniert wirklich, wenn Sie in einem Team von drei oder vier Personen sind. In diesem Maßstab weiß jeder, woran alle anderen arbeiten, das Verknüpfen ist eher ein Bonus als eine Notwendigkeit, und der gelegentlich fehlende Link spielt keine Rolle, weil Sie einfach fragen können.
Es hört auf zu funktionieren ungefähr dann, wenn Sie das gesamte Projekt nicht mehr im Kopf behalten können. Wenn Sie vier Workstreams betreiben und PRs für Features reviewen, die Sie nicht persönlich spezifiziert haben, wird die Verknüpfungsdisziplin kritisch – und gleichzeitig das Erste, das unter Druck zusammenbricht. Niemand vergisst seinen PR zu verknüpfen, weil er faul ist. Sie vergessen es, weil sie mitten im Code schreiben sind, drei Tabs offen haben, und das Kopieren einer Linear-URL in eine PR-Beschreibung genau die Art kleiner, feedbackloser Aufgabe ist, die das menschliche Gehirn spektakulär schlecht darin ist, konsequent zu erledigen.
Das eigentliche Problem: Zwei Wahrheitsquellen
Hier ist das, was mich eine Weile brauchte zu verstehen bezüglich dieser speziellen Reibung, und das ich für die eigentliche Grundursache halte.
Diese beiden Tools repräsentieren dieselbe Arbeit aus grundlegend verschiedenen Perspektiven. Linear zeigt Ihnen die Projektmanagement-Ansicht – Prioritäten, Sprints, wer zugewiesen ist, was blockiert ist. GitHub zeigt Ihnen die Code-Ansicht – was geschrieben, überprüft und gemergt wurde. Beide sind gültig. Beide sind notwendig. Aber sie beschreiben dieselbe Realität in verschiedenen Vokabularien, und die Übersetzung zwischen ihnen ist vollständig manuell.
„Beide sind gültig. Beide sind notwendig. Aber sie beschreiben dieselbe Realität in verschiedenen Vokabularien, und die Übersetzung zwischen ihnen ist vollständig manuell." – Chris Calo
Wenn ein PR auf GitHub gemergt wird, sagt die Code-Ansicht „erledigt". Wenn das Linear-Ticket noch nicht aktualisiert wurde, sagt die Projektansicht „in Bearbeitung". Beide sind in ihrem eigenen Kontext korrekt, und beide sind ohne das andere irreführend.
Dieses Problem mit zwei Wahrheitsquellen ist (ich denke) der fundamentale Grund, warum das ständige Tab-Wechseln so erschöpfend ist. Sie wechseln nicht nur Tools. Sie wechseln Weltanschauungen und versuchen dann, diese in Ihrem Kopf in Einklang zu bringen, bevor Sie eine Entscheidung treffen können.
Praktische Dinge, die Sie heute tun können
Bevor ich zur architektonischen Lösung komme (die, ja, einen Wissensgraph beinhaltet – ich arbeite bei einem Unternehmen, das einen baut, also nehmen Sie das mit angemessener Skepsis), hier sind konkrete Dinge, die helfen, den Wechselaufwand zu reduzieren:
Branch-Namenskonventionen. Die automatisch generierten Branch-Namen von Linear enthalten standardmäßig die Issue-ID. Kämpfen Sie nicht dagegen an. Lassen Sie die Maschine das Verknüpfen übernehmen.
PR-Templates. Erstellen Sie ein PR-Template, das ein „Linear-Ticket"-Feld enthält. GitHub unterstützt PR-Templates über .github/PULL_REQUEST_TEMPLATE.md – die zehn Minuten für die Einrichtung sparen Stunden an fehlenden Links.
Bidirektionaler Status. Wenn Ihre CI-Pipeline ausgereift genug ist, können Sie die Linear-API verwenden, um den Ticket-Status automatisch zu aktualisieren, wenn ein PR gemergt, überprüft wird oder Änderungen angefordert wurden. Das ist nicht trivial zu bauen (die Webhook-Behandlung hat einige Grenzfälle rund um Draft-PRs und Force-Pushes), eliminiert aber eine riesige Kategorie von Stale-State-Problemen.
Wöchentliche Abstimmung. Verbringen Sie jeden Freitag zehn Minuten damit, Ihr Linear-Board mit Ihren offenen PRs auf GitHub zu vergleichen. Markieren Sie alles, wo die Zustände nicht übereinstimmen. Ja, das ist peinlich manuell für Menschen, die Software schreiben – die Ironie ist mir nicht entgangen – aber es erkennt die Abweichung, bevor sie zum Problem wird, und ist unendlich besser, als die Diskrepanz während eines Sprint-Reviews zu entdecken.
Das sind gute Praktiken. Wir verwenden sie alle. Sie reduzieren den Schmerz des ständigen Kontextwechsels, eliminieren ihn aber nicht, weil das grundlegende Problem bestehen bleibt – zwei Tools, zwei Perspektiven, eine Realität.
Wie eine verbundene Ansicht tatsächlich aussieht
Die Alternative zum ständigen Wechseln ist ein System, das beide Tools versteht und Ihnen den kombinierten Zustand eines Arbeitsvorgangs zeigen kann, ohne dass Sie beide mentalen Modelle gleichzeitig im Kopf behalten müssen.
Konkret bedeutet das: Sie schauen auf eine Aufgabe und sehen die Priorität und den Sprint des Linear-Tickets neben dem Review-Status und den CI-Ergebnissen des GitHub-PRs neben dem Slack-Thread, in dem der Ansatz diskutiert wurde, neben den Figma-Designs, die gestern aktualisiert wurden. Nicht als Links, durch die Sie klicken – als Kontext, an einem Ort, mit bereits aufgelösten Beziehungen.
Das ist es, was wir mit Sugarbug bauen, und es ist nicht die einzige Möglichkeit, das zu lösen (manche Teams bauen interne Tools mit Webhooks und einem ordentlichen Frontend), aber das Prinzip ist dasselbe: Hören Sie auf, Menschen die Arbeit des Verbindens zweier Tools zu machen, die von Anfang an verbunden hätten sein sollen.
---
Sugarbug verknüpft Linear-Issues, GitHub-PRs, Slack-Threads und Figma-Kommentare in einem Wissensgraph – damit Sie aufhören zu wechseln und anfangen, das vollständige Bild zu sehen. Zur Warteliste
---
Verbinden Sie Linear, GitHub, Slack und Figma in einem Wissensgraph – und hören Sie auf, den Kontext manuell zu rekonstruieren.
Q: Reduziert Sugarbug den Bedarf, zwischen Linear und GitHub zu wechseln? A: Ja. Sugarbug verbindet sich über die API mit beiden Tools und erstellt einen Wissensgraph, der Issues, PRs, Branches und Gespräche verknüpft. Anstatt jedes Tool separat zu prüfen, erhalten Sie eine einheitliche Ansicht des Fortschritts – einschließlich zugehöriger Slack-Diskussionen und Figma-Designs.
Q: Kann Sugarbug einen GitHub-PR automatisch mit einem Linear-Issue verknüpfen? A: Sugarbug erkennt, wenn ein GitHub-PR auf ein Linear-Issue verweist (über Branch-Name, PR-Beschreibung oder Commit-Message), und verknüpft sie automatisch im Wissensgraph. Es verbindet auch zugehörige Slack-Diskussionen und Figma-Kommentare mit demselben Arbeitsvorgang, sodass der vollständige Kontext immer sichtbar ist, ohne durch jedes Tool zu klicken.
Q: Was leistet die native Linear-GitHub-Integration wirklich? A: Die integrierte GitHub-Integration von Linear synchronisiert den PR-Status mit Linear-Issues – wenn ein PR gemergt wird, kann das verknüpfte Issue automatisch geschlossen werden. Sie zeigt auch PR-Links auf der Issue-Detailseite an. Was sie nicht leistet: Kommentare synchronisieren, zugehörige Slack-Gespräche verbinden oder auf widersprüchliche Zustände hinweisen (wie ein gemergter PR mit ungelösten Review-Kommentaren bei einem Ticket, das als „Erledigt" markiert ist).
Q: Ist es besser, in Linear oder in GitHub Issues zu arbeiten? A: Sie dienen unterschiedlichen Zwecken. Linear ist für Projektplanung ausgelegt – Sprints, Zyklen, Prioritäten, Roadmaps. GitHub Issues ist für Code-Level-Tracking ausgelegt – Bugs, Feature-Anfragen, die an bestimmte Repos gebunden sind. Die meisten Engineering-Teams nutzen letztlich beide (oder zumindest Linear plus GitHub-PRs), was genau der Grund ist, warum der Wechselaufwand zählt und warum es die Mühe wert ist, sie richtig zu verbinden.