GitHub a annoncé le 6 octobre 2026 le passage en disponibilité générale des pull requests empilées (stacked pull requests), une fonctionnalité qui permet de découper un gros changement en plusieurs PR plus petites, relisables indépendamment puis fusionnées ensemble. La fonctionnalité était en preview publique depuis le 30 juillet 2026 ; elle est désormais disponible sur tous les plans de github.com, et une version pour GitHub Enterprise Server est annoncée sans date précise.
Ce que la préversion a montré
Pendant la phase de preview, GitHub indique que les dépôts utilisant les stacks ont fusionné 9 % de code en plus que des dépôts comparables, avec un temps de fusion réduit de 5 %. Plus des deux tiers des dépôts du top 1 % de l’activité GitHub utilisent déjà ce mécanisme, un indicateur d’adoption chez les équipes à fort volume de contributions.
Fusion et rebasage : le changement de fond
La bascule en disponibilité générale porte surtout sur la mécanique de fusion. La commande rebase stack préserve désormais les approbations déjà données sur du code inchangé, même dans les dépôts configurés pour invalider les approbations à chaque nouveau commit. Les commits rebasés restent signés si les règles de branche l’exigent ou si les commits d’origine l’étaient, et l’auteur d’origine est conservé.
Une stack entre et progresse dans la merge queue comme un groupe de fusion unique : avec la méthode de fusion par merge commit, GitHub crée un commit de fusion par PR. Si la branche de base d’une stack est supprimée, la stack est retargetée automatiquement plutôt que de voir sa PR du bas fermée, ce qui autorise des stacks branchées sur d’autres stacks.
| Aspect | Avant (preview) | À la disponibilité générale |
|---|---|---|
| Rebasage | Invalidait les approbations | Préserve les approbations sur le code inchangé |
| Fusion | PR par PR | Groupe de fusion unique via la merge queue |
| Branche de base supprimée | Fermeture de la PR du bas | Retargetage automatique de la stack |
| Fusion automatique | Non disponible | Déploiement progressif sur plusieurs semaines |
Navigation et automatisation
Les informations de stack apparaissent désormais dans l’en-tête persistant de la page de PR et dans la liste des pull requests. Les raccourcis Shift+J et Shift+K permettent de circuler entre les PR d’une même stack, et la timeline affiche les ajouts ou retraits d’une PR dans une stack. Le webhook pull_request expose désormais une action stacked lorsqu’une PR rejoint une stack, ce qui ouvre la porte à des automatisations CI spécifiques, par exemple pour ajuster la stratégie de mise en cache des workflows GitHub Actions selon qu’une PR appartient à une stack ou non.
L’extension CLI gh stack gagne un support des worktrees Git et une initialisation, un checkout et une navigation plus rapides. Un développeur travaillant sur plusieurs stacks en parallèle peut désormais le faire sans multiplier les clones.
gh stack create feature/refonte-auth
gh stack push
gh stack sync # rebase + mise à jour de la stack entière
gh stack ls # liste les PR de la stack courante
Plus des deux tiers des dépôts du top 1 % de l’activité GitHub utilisent déjà les pull requests empilées.
La fusion automatique des stacks est en déploiement progressif sur plusieurs semaines : une équipe qui ne la voit pas encore apparaître dans ses paramètres de dépôt n’a rien à configurer de son côté, il s’agit d’un rollout côté GitHub.
Pour les équipes qui pratiquent déjà le découpage manuel
Les équipes qui empilaient déjà leurs PR à la main, par convention de nommage ou via des outils tiers, peuvent migrer sans changer leur façon de travailler : les mêmes commandes de CLI de développement restent valables, GitHub ajoute la mécanique de fusion groupée par-dessus. L’intérêt principal reste la relecture : une PR de 2 000 lignes se transforme en cinq PR de 400 lignes, chacune avec son propre contexte de revue.
Ce qu’il faut retenir
Les pull requests empilées sortent de la preview avec une mécanique de fusion plus robuste : approbations préservées au rebasage, fusion groupée via la merge queue, et une extension CLI plus rapide. La fonctionnalité est accessible sur tous les plans github.com dès aujourd’hui, sans action requise pour les dépôts qui ne l’utilisent pas encore.
Les stacks règlent un vrai problème de revue de code, mais elles demandent une discipline que beaucoup d’équipes n’ont pas encore : si une PR du milieu de la stack change radicalement après une relecture, tout ce qui suit doit être rebasé, et c’est là que les mérites du rebasage automatique de GitHub se mesurent vraiment. À tester avant de l’imposer en convention d’équipe. — Simon Janvier
Pour aller plus loin : l’annonce officielle sur le changelog GitHub.
