Vous avez déjà passé 45 minutes à reviewer une pull request de 3000 lignes ? Vous n’êtes pas seul. La revue de code sur des PR monolithiques reste l’un des pires goulets d’étranglement du cycle de développement. Le 30 juillet 2026, GitHub a enfin sorti une réponse crédible à ce problème avec l’ouverture en preview publique des Stacked PRs.
Je suis Mehdi Rahmani, freelance en sécurité et DevOps, et je décortique pour vous cette sortie majeure. La promesse est simple : découper une grosse fonctionnalité en plusieurs PRs ciblées, les chaîner logiquement, les reviewer indépendamment et tout fusionner d’un clic. Voyons ce que ça donne sur le terrain.
Qu’est-ce que les Stacked PRs GitHub ?
Les Stacked PRs sont une série ordonnée de pull requests, chacune représentant une couche ciblée d’un changement plus vaste. Chaque PR de la pile cible la couche inférieure, et non directement la branche main. L’ensemble forme une chaîne de dépendances que GitHub gère nativement.
Concrètement, au lieu d’ouvrir une PR unique de 2000 lignes qui terrorise vos reviewers, vous créez quatre PRs de 500 lignes. Chacune peut être relue en parallèle par des personnes différentes. Le statut de chaque couche reste visible en un coup d’oeil depuis l’interface GitHub. Et quand tout est prêt, vous fusionnez la pile entière en une seule opération.
Cette approche existait déjà via des outils tiers comme Graphite ou Git Town. Ce qui change ici, c’est l’intégration native : vos règles de protection de branche, vos checks obligatoires et vos merge queues fonctionnent sans adaptation. Citations de l’annonce officielle : Tim Neutkens, lead de Next.js chez Vercel, confirme que l’équipe utilise les Stacked PRs depuis plusieurs mois pour « introduire des changements individuels plus petits tout en livrant des fonctionnalités plus larges ». John Resig, créateur de jQuery, qualifie l’expérience de « incroyable » après avoir fusionné cinq PRs empilées d’un coup via la merge queue.
Pourquoi les équipes DevOps les réclamaient depuis des années
Le problème est connu de toute personne qui évolue dans une codebase conséquente. Les PRs volumineuses génèrent trois frictions majeures :
- Revues interminables : un reviewer qui reçoit 3000 lignes à analyser va soit survoler, soit procrastiner. Dans les deux cas, le code stagne.
- Conflits de merge en cascade : quand plusieurs développeurs travaillent sur des branches longue durée, les rebases deviennent un cauchemar logistique.
- Feedback tardif : une PR monolithique concentre tous les retours à la fin du développement. Les erreurs d’architecture se découvrent trop tard.
Les Stacked PRs attaquent ces trois problèmes à la racine. Chaque couche est suffisamment petite pour être reviewée rapidement. Les rebases se propagent automatiquement le long de la pile via un mécanisme de cascade. Et les retours arrivent au fil de l’eau, couche par couche.
Andy Merryman, CTO de TED, résume bien l’enjeu dans le changelog GitHub : « L’IA a rendu nos développeurs nettement plus productifs, mais cela a créé un nouveau goulet d’étranglement : les PRs devenaient trop volumineuses pour les reviewers. Les Stacked PRs aident à résoudre ça. »
Comment ça marche concrètement
Installation via la CLI
L’accès à la preview publique se fait sans liste d’attente. Une simple commande suffit :
gh extension install github/gh-stack
Vous créez ensuite votre première pile en quelques minutes. La fonctionnalité est disponible depuis le terminal, l’interface web github.com, l’application mobile GitHub et même via GitHub Copilot grâce à la compétence gh-stack.
Navigation et revue par couche
Chaque PR de la pile affiche un diff qui ne contient que les changements propres à sa couche. Une carte visuelle en haut de la PR montre où se situe la couche dans l’ensemble du travail. Vous voyez immédiatement le nombre de PRs, leur statut et l’ordre des dépendances.
Vos équipiers peuvent reviewer différentes couches en parallèle sans se bloquer mutuellement. Les branch protections et les checks requis continuent de s’appliquer normalement.
Fusion en un clic avec la merge queue
C’est le point fort de l’intégration native. Vous fusionnez la PR la plus haute de la pile, et toutes les couches non fusionnées en dessous atterrissent sur main en une seule opération. Si vous voulez fusionner seulement une partie de la pile, mergez une couche inférieure : les PRs au-dessus restent ouvertes et se rebasent automatiquement sur la nouvelle cible.
La merge queue supporte les Stacked PRs de manière progressive : le déploiement de cette compatibilité s’étale sur les semaines qui suivent la sortie.
Premiers retours : enthousiasme et bugs de jeunesse
Le lancement a généré un engouement massif. Les équipes qui testaient la preview en interne depuis plusieurs mois, comme celles de Next.js ou TED, livrent des retours très positifs.
Mayank Saini, ingénieur connectivité chez WHOOP, témoigne dans l’annonce officielle : « Un gros changement signifiait avant une PR géante que personne ne voulait reviewer. Maintenant, c’est une pile de petites PRs que les reviewers peuvent vraiment suivre. »
Cependant, la preview publique révèle aussi des fragilités. Plusieurs utilisateurs rapportent que la fusion d’une pile entière peut échouer dans des cas complexes, notamment quand des conflits subtils apparaissent entre les couches lors de l’opération de merge. Le mode squash and merge pose également problème : si les revues sont obligatoires, chaque PR de la pile exige une ré-approbation après le squash, ce qui casse la promesse de fluidité.
L’équipe GitHub n’a pas encore communiqué officiellement sur ces points. La discussion reste ouverte sur le dépôt github/gh-stack, et les corrections dépendront des retours de la communauté pendant cette phase de preview.
Stacked PRs natives vs outils tiers : match prématuré ?
Une question revient dans toutes les discussions : quel avenir pour Graphite, Git Town et les autres outils spécialisés ?
La réponse est nuancée. La preview publique est trop récente pour établir une comparaison équitable. Les outils tiers ont des années de maturation, des workflows éprouvés et des fonctionnalités avancées que GitHub n’intègre pas encore. Mais l’intégration native possède un atout massif : elle ne demande aucun changement d’habitude, aucun onboarding d’équipe, aucun contrat payant supplémentaire.
Si GitHub corrige rapidement les bugs de fusion et assouplit le comportement du squash and merge, l’écosystème des outils spécialisés devra se différencier sur des cas d’usage avancés. À l’inverse, si la preview reste fragile plusieurs mois, les équipes qui ont déjà adopté Graphite n’auront aucune raison de migrer.
Ce qu’il faut retenir
- Les Stacked PRs sont disponibles en preview publique depuis le 30 juillet 2026, sans liste d’attente.
- Elles permettent de chaîner des PRs dépendantes, de les reviewer en parallèle et de tout fusionner en un clic via la merge queue.
- L’intégration native respecte les branch protections, les checks requis et les workflows existants.
- Des bugs de jeunesse persistent sur la fusion de pile complète et le comportement en squash and merge.
- L’impact sur les outils tiers comme Graphite dépendra de la vitesse de correction de GitHub dans les mois à venir.
Si vous testez les Stacked PRs sur vos projets, je suis curieux d’avoir vos retours. Passez me voir sur mehdi-rahnani.dev ou suivez le blog pour ne pas rater les prochaines analyses.
Sources
- GitHub Changelog : Stacked pull requests are now in public preview, 30 juillet 2026
- Documentation officielle gh-stack, GitHub
- Dépôt github/gh-stack : discussions sur les bugs de fusion, GitHub Community