Les pull requests empilées de GitHub passent en disponibilité générale avec 9 % de code fusionné en plus
GitHub annonce la disponibilité générale des pull requests empilées, qui découpent une grosse évolution en petites demandes revues indépendamment puis fusionnées ensemble. Si vos branches se bloquent les unes les autres, les chiffres de GitHub — 9 % de code fusionné en plus, 5 % de délai de fusion en moins — justifient de les adopter dès maintenant.
6 octobre 2026. GitHub passe les pull requests empilées (stacked pull requests) en disponibilité générale, un an après leur entrée en préversion publique le 30 juillet 2026. Le principe tient en une phrase : découper une grosse évolution en une série de petites demandes de revue indépendantes, reliées entre elles, que l’on fusionne ensemble à la fin. Pourquoi c’est important : c’est la réponse directe au problème structurel de la grosse PR, celle qui traîne pendant des semaines parce qu’elle mélange dix décisions dans un seul diff illisible.
Ce que la disponibilité générale change concrètement
La version définitive n’est pas qu’un changement de statut. GitHub a ajouté six mécanismes qui corrigent les irritants signalés pendant la préversion.
Le premier concerne la conservation des approbations. Lorsque vous rebasez une pile dont la branche de base a avancé, la commande Rebase stack préserve désormais les approbations déjà données, même dans les dépôts configurés pour invalider les approbations obsolètes. Pour une équipe qui empile cinq PR, c’est la fin du cauchemar où un rebase annule quatre revues validées.
Le deuxième porte sur la signature des commits. Les commits de remplacement créés pendant un rebase restent signés et conservent la paternité d’origine, y compris lors des rebases automatiques après fusion partielle. Les dépôts qui imposent des commits signés par règle de branche ne cassent donc plus la pile.
Trois ajustements simplifient la fusion elle-même. Les utilisateurs autorisés à contourner les règles de dépôt peuvent désormais fusionner la PR la plus basse de la pile avec ce droit. Une pile entre et ressort de la merge queue comme un groupe de fusion unique, et la méthode merge commit produit désormais un commit par PR au lieu d’un seul pour tout le groupe. Enfin, lorsqu’une branche de base est supprimée, la pile est reciblée automatiquement au lieu de fermer sa PR du bas.
Le dernier ajout, l’auto-merge, arrive progressivement dans les prochaines semaines : on sélectionne un groupe de PR et elles fusionnent ensemble dès que leurs conditions de fusion sont réunies.
Les chiffres de la préversion donnent le verdict
GitHub a mesuré l’effet sur les dépôts qui ont adopté la fonctionnalité pendant la préversion. Les résultats sont nets : 9 % de code fusionné en plus par rapport aux dépôts comparables, et 5 % d’amélioration du délai de fusion (time-to-merge). Plus parlant encore, plus des deux tiers des dépôts du premier centile utilisent déjà les PR empilées.
Traduit pour un responsable d’équipe : ce n’est pas un gadget de confort, c’est un levier mesurable sur le débit de livraison. Le 9 % de code en plus vient du fait qu’une pile élimine le coût de coordination qui entoure une grosse PR — les allers-retours de revue sur un diff de 3 000 lignes, les rebases douloureux, les branches mortes en attente d’une fusion que personne n’ose déclencher.
Charlie Marsh, fondateur d’Astral et d’OpenAI, résume la bascule en une phrase citée par GitHub : « Il m’a fallu une seule fusion avec les PR empilées pour conclure que c’est formidable. »
Le workflow au quotidien
Concrètement, une pile se construit en branchant chaque PR sur la précédente. La PR du bas porte la branche de base réelle, la suivante se branche dessus, et ainsi de suite. La revue se fait du haut vers le bas ou du bas vers le haut selon l’équipe, mais chaque diff reste petit et lisible — c’est tout l’intérêt.
La navigation a été soignée pour la GA. Le contexte de la pile reste visible en permanence dans l’en-tête de la page de PR, et deux raccourcis clavier — Maj+J et Maj+K — permettent de circuler entre les PR d’une même pile. Le webhook pull_request expose désormais une action stacked quand une PR rejoint une pile, ce qui ouvre l’automatisation des notifications et des contrôles d’intégration.
Côté ligne de commande, l’extension gh stack du GitHub CLI prend en charge les worktrees Git et accélère l’initialisation, le checkout et la navigation. Pour les workflows d’agents, cela signifie qu’un agent de codage peut manipuler une pile aussi proprement qu’un humain.
La discipline qui fait ou défait une pile n’est pas l’outil, c’est l’ordre de revue. La convention la plus robuste consiste à revoir du bas vers le haut — la PR de base d’abord, puis chaque PR en remontant — car la PR du bas fixe les fondations que les suivantes étendent. Revoir dans le désordre revient à valider des étages dont les fondations peuvent encore bouger, et c’est la source la plus fréquente de re-revues inutiles quand une PR du bas change après coup. Une règle simple vaut mieux qu’un long document : on ne fusionne jamais une PR tant que la PR du dessous n’est pas approuvée.
Un point de vigilance subsiste : la fonctionnalité est disponible sur github.com pour tous les plans, mais n’arrivera sur GitHub Enterprise Server que dans une prochaine version. Les équipes en GHES devront donc attendre avant d’aligner leur workflow interne sur celui de leurs dépôts publics.
Où ça se situe face au trunk-based et aux outils tiers
Les PR empilées ne sont pas une idée neuve : des outils comme Graphite, ghstack ou Sapling proposaient déjà cette mécanique, souvent hors de GitHub, au prix d’un workflow parallèle et d’outillage supplémentaire. La force de la version native est de ramener la pile dans l’interface — l’état de la pile, les approbations, les signatures, la merge queue — là où l’équipe travaille déjà, sans dépendance externe à installer et maintenir.
La question de fond, pour un responsable d’équipe, est de savoir où placer le curseur entre deux philosophies de livraison. Le trunk-based development préconise des PR petites et indépendantes, fusionnées très vite sur main, avec le feature flag comme mécanisme de masquage du code inachevé. Les PR empilées répondent au même objectif — découper — mais en gardant la relation de dépendance entre les morceaux, ce qui convient mieux aux chantiers où l’ordre de fusion compte, comme une migration de schéma suivie d’un changement d’API.
Les deux approches ne s’excluent pas. Une équipe mature en trunk-based utilisera les empilées pour l’exception — la refonte transverse qui touche cinq services — et gardera ses petites PR indépendantes pour le reste. C’est d’ailleurs ce que suggèrent les chiffres de GitHub : l’adoption ne remplace pas le découpage, elle le structure quand les morceaux sont inséparables.
Verdict
Si votre équipe découpe déjà ses évolutions en branches dépendantes, ou si vos PR se bloquent régulièrement les unes les autres, adoptez les PR empilées dès aujourd’hui : le 5 % de délai de fusion en moins se paie en une semaine d’adaptation du workflow, et la conservation des approbations au rebase lève le principal risque opérationnel. Si votre équipe fusionne déjà en trunk avec de petites PR indépendantes, le gain sera plus marginal — gardez les empilées pour les chantiers transverses qui touchent plusieurs couches à la fois. Si vous êtes en GHES, préparez la migration de vos conventions de revue maintenant, mais n’attendez pas la sortie serveur pour former vos développeurs sur github.com. Dans tous les cas, commencez petit : une pile de deux ou trois PR sur un chantier réel, pas une refonte du processus entier du jour au lendemain.