Arrêtez de Basculer entre Linear et GitHub
Pourquoi les développeurs perdent des heures entre Linear et GitHub, ce que fait l'intégration native et comment unifier les deux outils.
By Ellis Keane · 2026-03-17
Le nom de la branche était feat/onboarding-email-verification. Le ticket Linear indiquait : « Implémenter le flux de vérification par e-mail – priorité : urgente. » Le PR GitHub avait trois commentaires de révision, dont deux non résolus. Et quelque part dans un fil Slack du mardi précédent, notre designer avait signalé que le texte de l'e-mail de vérification devait être mis à jour avant le déploiement.
Je savais que tout cela existait. Je ne savais juste pas que tout cela concernait le même travail – jusqu'à ce que j'aie passé vingt minutes à naviguer entre Linear, GitHub, Slack et ma propre mémoire de plus en plus défaillante.
Si vous avez déjà travaillé dans une équipe qui utilise à la fois Linear et GitHub (ce qui, à ce stade, décrit à peu près toutes les équipes d'ingénierie qui ont décidé que Jira est une punition plutôt qu'un outil), vous savez exactement de quoi je parle. Le changement de contexte constant entre Linear et GitHub n'est pas une simple nuisance – c'est une véritable taxe sur votre capacité à comprendre simultanément ce qui se passe dans votre base de code et dans votre plan de projet.
Le mythe : ces outils communiquent entre eux
Linear dispose d'une intégration GitHub. C'est l'une des premières choses que vous configurez. Et elle fonctionne – d'une manière spécifique et limitée qu'il vaut la peine de comprendre précisément, car l'écart entre ce que les gens pensent qu'elle fait et ce qu'elle fait réellement est l'endroit où réside la plupart de la douleur.
Voici ce que l'intégration GitHub de Linear gère réellement : lorsque vous créez une branche à partir d'un issue Linear, le nom de la branche inclut l'ID de l'issue. Lorsqu'un PR faisant référence à cet ID est fusionné, Linear peut faire passer automatiquement l'issue à « Terminé ». Vous pouvez voir les liens vers les PRs sur la page de détail de l'issue Linear. C'est réellement utile, et je ne veux pas le minimiser.
Ce qu'elle ne gère pas : la synchronisation des commentaires entre les deux plateformes. Le signalement d'un PR ayant des commentaires de révision non résolus alors que le ticket Linear a été déplacé vers « Terminé ». La connexion de la discussion Slack où l'approche a été débattue avec l'issue ou le PR. L'affichage de la mise à jour des designs Figma après l'ouverture du PR. La connaissance que l'exigence derrière ce ticket a été silencieusement déprioritisée dans un document Notion la semaine dernière.
L'intégration gère le lien mécanique – issue vers PR. Elle ne gère pas le réseau contextuel autour des deux. Et ce réseau contextuel est précisément ce que vous essayez de reconstruire chaque fois que vous basculez entre Linear et GitHub.
Ce qui se passe réellement quand vous changez de contexte
Laissez-moi décrire à quoi ressemble un changement de contexte typique entre Linear et GitHub, car je pense que les gens sous-estiment l'effort cognitif impliqué.
Vous êtes dans Linear. Vous voyez un ticket marqué « En révision ». Vous voulez connaître l'état de la révision, donc vous cliquez pour accéder au PR sur GitHub. Vous lisez maintenant les commentaires de révision, mais vous avez perdu le contexte du ticket Linear – la priorité, les critères d'acceptation, les sous-tâches liées. Vous revenez à Linear. Vous avez maintenant perdu votre place dans les commentaires de révision. Vous revenez à GitHub. Un réviseur a mentionné quelque chose d'une conversation Slack, donc vous ouvrez Slack et cherchez le fil. Vingt minutes se sont écoulées (je le sais, parce que je me suis chronométré en faisant exactement ça), et vous n'avez toujours pas une image complète de si ce ticket est vraiment prêt à être déployé.
Le problème n'est pas qu'un outil individuel est mauvais. Linear est excellent dans ce qu'il fait. GitHub est excellent dans ce qu'il fait. Le problème est que « ce qu'il fait » s'arrête à la frontière de chaque outil, et le travail que vous essayez de comprendre ne respecte pas ces frontières.
Basculer entre Linear et GitHub n'est pas juste un problème de gestion d'onglets. C'est un problème de reconstruction du contexte – chaque changement vous force à reconstruire le modèle mental du travail depuis la perspective d'un outil différent.
Pourquoi « il suffit de tout lier » ne passe pas à l'échelle
Le conseil standard ici est d'être discipliné sur les liens. Chaque description de PR devrait inclure l'URL du ticket Linear. Chaque ticket Linear devrait pointer vers son PR. Chaque message de commit devrait référencer l'issue.
Et ça fonctionne, vraiment, si vous êtes dans une équipe de trois ou quatre personnes. À cette échelle, tout le monde sait sur quoi tout le monde travaille, les liens sont davantage un plus qu'une nécessité, et le lien manquant occasionnel n'a pas d'importance parce que vous pouvez simplement demander.
Ça cesse de fonctionner à peu près au moment où vous ne pouvez plus garder l'ensemble du projet en tête. Si vous gérez quatre flux de travail et révisez des PRs pour des fonctionnalités que vous n'avez pas personnellement spécifiées, la discipline de liaison devient critique – et c'est aussi la première chose qui s'effondre sous pression. Personne n'oublie de lier son PR parce qu'il est paresseux. Il oublie parce qu'il est en train d'écrire du code, qu'il a trois onglets ouverts, et que l'acte de copier une URL Linear dans une description de PR est exactement le genre de petite tâche sans retour que le cerveau humain fait spectaculairement mal de façon constante.
Le vrai problème : deux sources de vérité
Voici ce qui m'a pris du temps à comprendre à propos de cette friction particulière, et que je pense être la vraie cause fondamentale.
Ces deux outils représentent le même travail depuis des perspectives fondamentalement différentes. Linear vous montre la vue gestion de projet – priorités, sprints, qui est assigné, ce qui est bloqué. GitHub vous montre la vue code – ce qui a été écrit, révisé, fusionné. Les deux sont valides. Les deux sont nécessaires. Mais ils décrivent la même réalité dans des vocabulaires différents, et la traduction entre eux est entièrement manuelle.
« Les deux sont valides. Les deux sont nécessaires. Mais ils décrivent la même réalité dans des vocabulaires différents, et la traduction entre eux est entièrement manuelle. » – Chris Calo
Lorsqu'un PR est fusionné sur GitHub, la vue code dit « terminé ». Lorsque le ticket Linear n'a pas encore été mis à jour, la vue projet dit « en cours ». Les deux sont corrects dans leur propre contexte, et les deux sont trompeurs sans l'autre.
Ce problème de double source de vérité est (je crois) la raison fondamentale pour laquelle le changement constant d'onglets est si épuisant. Vous ne changez pas seulement d'outils. Vous changez de vision du monde, puis vous essayez de les réconcilier dans votre tête avant de pouvoir prendre une décision.
Des choses pratiques que vous pouvez faire aujourd'hui
Avant d'arriver à la solution architecturale (qui, oui, implique un graphe de connaissances – je travaille dans une entreprise qui en construit un, donc prenez cela avec le recul approprié), voici des choses concrètes qui aident à réduire le coût du changement de contexte :
Conventions de nommage des branches. Les noms de branches générés automatiquement par Linear incluent l'ID de l'issue par défaut. Ne combattez pas ça. Laissez la machine faire les liens.
Templates de PR. Créez un template de PR qui inclut un champ « Ticket Linear ». GitHub prend en charge les templates de PR via .github/PULL_REQUEST_TEMPLATE.md – les dix minutes pour configurer ça vous feront économiser des heures de liens manquants.
Statut bidirectionnel. Si votre pipeline CI est suffisamment sophistiqué, vous pouvez utiliser l'API Linear pour mettre à jour automatiquement l'état du ticket lorsqu'un PR est fusionné, révisé ou a des changements demandés. Ce n'est pas trivial à construire (la gestion des webhooks a quelques cas limites autour des PRs en brouillon et des force-pushes), mais ça élimine une énorme catégorie de problèmes d'état obsolète.
Réconciliation hebdomadaire. Consacrez dix minutes chaque vendredi à comparer votre tableau Linear avec vos PRs ouverts sur GitHub. Signalez tout ce où les états ne correspondent pas. Oui, c'est embarrassamment manuel pour des personnes qui écrivent des logiciels – l'ironie ne m'échappe pas – mais ça détecte la dérive avant qu'elle ne devienne un problème, et c'est infiniment mieux que de découvrir la discordance lors d'une revue de sprint.
Ce sont de bonnes pratiques. Nous les utilisons toutes. Elles réduisent la douleur du changement de contexte constant, mais ne l'éliminent pas, car le problème fondamental – deux outils, deux perspectives, une réalité – demeure.
À quoi ressemble réellement une vue connectée
L'alternative au changement constant est un système qui comprend les deux outils et peut vous montrer l'état combiné d'un élément de travail sans vous obliger à maintenir les deux modèles mentaux simultanément.
Concrètement, ça signifie : vous regardez une tâche et vous voyez la priorité et le sprint du ticket Linear à côté du statut de révision et des résultats CI du PR GitHub à côté du fil Slack où l'approche a été discutée à côté des designs Figma mis à jour hier. Pas sous forme de liens sur lesquels cliquer – comme du contexte, en un seul endroit, avec les relations déjà résolues.
C'est ce que nous construisons avec Sugarbug, et ce n'est pas la seule façon de résoudre ça (certaines équipes construisent des outils internes avec des webhooks et un frontend correct), mais le principe est le même : cessez de faire faire aux humains le travail de connecter deux outils qui auraient dû être connectés dès le départ.
---
Sugarbug relie les issues Linear, les PRs GitHub, les fils Slack et les commentaires Figma dans un graphe de connaissances – pour que vous cessiez de basculer et commenciez à voir le tableau complet. Rejoindre la liste d'attente
---
Connectez Linear, GitHub, Slack et Figma dans un graphe de connaissances – et arrêtez de reconstruire le contexte manuellement.
Q: Sugarbug réduit-il le besoin de basculer entre Linear et GitHub ? A: Oui. Sugarbug se connecte aux deux outils via API et construit un graphe de connaissances qui relie les issues, les PRs, les branches et les conversations. Au lieu de consulter chaque outil séparément, vous obtenez une vue unifiée de l'avancement, y compris les discussions Slack et les designs Figma associés.
Q: Sugarbug peut-il relier automatiquement un PR GitHub à un issue Linear ? A: Sugarbug détecte quand un PR GitHub fait référence à un issue Linear (via le nom de la branche, la description du PR ou le message de commit) et les relie automatiquement dans son graphe de connaissances. Il connecte également les discussions Slack et les commentaires Figma associés au même élément de travail, de sorte que le contexte complet est toujours visible sans avoir à cliquer sur chaque outil.
Q: Que fait réellement l'intégration native entre Linear et GitHub ? A: L'intégration GitHub intégrée à Linear synchronise le statut des PRs avec les issues Linear – lorsqu'un PR est fusionné, l'issue lié peut se fermer automatiquement. Elle affiche également les liens vers les PRs sur la page de détail de l'issue. Ce qu'elle ne fait pas : synchroniser les commentaires, connecter les conversations Slack associées ou signaler des états contradictoires (comme un PR fusionné avec des commentaires de révision non résolus sur un ticket marqué « Terminé »).
Q: Vaut-il mieux suivre le travail dans Linear ou dans GitHub Issues ? A: Ils servent des objectifs différents. Linear est conçu pour la planification de projet – sprints, cycles, priorités, feuilles de route. GitHub Issues est conçu pour le suivi au niveau du code – bugs et demandes de fonctionnalités liées à des dépôts spécifiques. La plupart des équipes d'ingénierie finissent par utiliser les deux (ou au moins Linear plus les PRs GitHub), ce qui est exactement pourquoi le coût du changement de contexte est important et pourquoi il vaut la peine de les connecter correctement.