Les stacked pull requests de GitHub sont désormais disponibles pour tous

GitHub a rendu les stacked pull requests disponibles pour tous le 6 octobre 2026, sur toutes les offres github.com. Une pile permet à un développeur de découper une grosse modification en une chaîne de petites pull requests, relues une par une, puis fusionnées ensemble. La fonction était en préversion publique depuis le 30 juillet, et GitHub affirme que les équipes qui l'utilisent fusionnent déjà plus de code.

Ce qu'est une stacked pull request

Une pull request (PR) demande de fusionner une branche de code dans une autre. Les grosses PR sont lentes à relire, car le relecteur doit tout comprendre d'un coup.

Une pile découpe ce travail en couches. Chaque PR cible la branche située en dessous, si bien que chacune ne montre que sa propre part des modifications. La PR du bas cible la branche principale, souvent appelée trunk. Selon le changelog de GitHub, chaque couche reçoit ses propres relectures et vérifications avant que les couches n'atterrissent ensemble.

La fusion se fait de bas en haut. CCLeaks, qui a publié un guide de mise en place le 8 octobre, explique que fusionner une PR fait aussi atterrir toutes les PR non fusionnées situées en dessous. Fusionner la PR du haut fusionne toute la pile. Les règles de branche s'appliquent toujours à chaque couche, y compris les relectures obligatoires, les vérifications de statut et les code owners.

Ce qui change avec la disponibilité générale

Le changelog du 6 octobre liste ces changements depuis la préversion :

Changement	Ce qu'il fait
Les approbations survivent aux rebases	Rebaser une pile conserve les approbations sur le code inchangé, même dans les dépôts qui annulent les approbations périmées
Commits signés	Les commits réécrits lors d'un rebase de pile restent signés et gardent leur auteur d'origine
Merge queue	Une pile entre dans la file de fusion comme un seul groupe et atterrit d'un bloc
Commits de fusion	Avec la méthode merge commit, chaque PR de la pile reçoit son propre commit de fusion
Branche de base supprimée	La pile est reciblée au lieu que sa PR du bas soit fermée
Fusions en contournement	Les utilisateurs autorisés à contourner les règles du dépôt peuvent fusionner la plus basse PR non fusionnée

La fusion automatique des piles est encore en cours de déploiement « dans les prochaines semaines », selon GitHub. L'en-tête des PR affiche désormais les détails de la pile, et la chronologie indique quand une PR rejoint ou quitte une pile. Les webhooks gagnent une action stacked sur l'événement pull_request. GitHub Enterprise Server, l'édition auto-hébergée, recevra les piles « dans une prochaine version ».

Les chiffres avancés par GitHub

GitHub affirme que les dépôts qui utilisent les piles ont fusionné 9 % de code de plus que des dépôts comparables. L'entreprise fait aussi état d'une amélioration de 5 % du délai de fusion. Ce sont les propres chiffres de GitHub, et le changelog n'explique pas comment le groupe de comparaison a été choisi.

Les premiers utilisateurs semblent satisfaits. « Il m'a suffi d'une fusion avec les Stacked PRs de GitHub pour conclure que c'est formidable », déclare Charlie Marsh, fondateur d'Astral, cité dans le changelog. Dans l'annonce de la préversion en juillet, Tim Neutkens, responsable de Next.js chez Vercel, a déclaré : « Nous utilisons les stacked PRs de GitHub pour Next.js depuis quelques mois. »

Comment lancer une pile

Les piles se pilotent avec gh stack, une extension de la GitHub CLI, l'outil en ligne de commande de GitHub. CCLeaks indique comme prérequis GitHub CLI 2.90.0 ou plus récent et Git 2.20 ou plus récent. La version GA prend en charge les worktrees de Git, qui permettent à un même dépôt de garder plusieurs branches extraites dans des dossiers séparés.

Le déroulé de base, selon le guide de CCLeaks :

1. Installer l'extension avec gh extension install github/gh-stack.
2. Lancer gh stack init pour démarrer une pile, puis gh stack add <branch> pour chaque couche.
3. Lancer gh stack submit pour ouvrir les PR, et gh stack view pour voir la chaîne.
4. Lancer gh stack rebase quand la branche de base avance.

Selon l'annonce de la préversion en juillet, les piles peuvent aussi être créées sur github.com, dans l'application mobile GitHub, ou par un agent de code comme GitHub Copilot grâce au skill gh-stack. Dans l'interface web, Shift+J et Shift+K permettent de passer d'une PR à l'autre dans une pile.

Les limites à connaître d'abord

La fonction a des limites nettes. CCLeaks liste celles-ci :

• Un seul dépôt. Toutes les branches doivent se trouver dans le même dépôt, donc les piles entre forks ne fonctionnent pas.
• Lignes droites uniquement. Une pile ne peut pas se ramifier ; une PR ne peut pas avoir deux enfants.
• Pas de GitHub Desktop. L'application de bureau ne prend pas en charge les piles.
• Les anciens endpoints de fusion échouent. Les endpoints historiques de l'API de fusion des PR ne peuvent pas fusionner une pile.
• Des groupes de file plus gros. Le groupe d'une pile dans la file de fusion peut dépasser la taille maximale configurée de 50 % au plus. Éjecter une PR retire aussi toutes les PR situées au-dessus.

Ce que cela change pour les développeurs

Les équipes qui découpent à la main de gros travaux en branches dépendantes disposent désormais d'un flux intégré. Avant de basculer, quelques vérifications s'imposent.

• Vérifiez votre automatisation. Les bots qui fusionnent via d'anciens endpoints de l'API échoueront sur les piles. CCLeaks indique que les données de pile arrivent dans GitHub Actions sous la forme github.event.pull_request.stack, et que le champ stack de l'API REST vaut null pour une PR isolée. Mettez à jour les bots de fusion pour qu'ils le lisent.
• Revoyez les limites de la file de fusion. Si votre file plafonne la taille des groupes pour protéger la capacité de CI, une pile peut pousser un groupe jusqu'à 50 % au-delà de ce plafond.
• Les contributeurs venus de forks devront attendre. Les projets open source qui acceptent des modifications depuis des forks ne peuvent pas encore empiler ces PR.
• Planifiez plus tard les mises à niveau d'Enterprise Server. Les clients auto-hébergés n'ont pas de date, seulement « une prochaine version ».
• Essayez sur une grosse modification. Une refonte qui touche de nombreux fichiers est un premier test tout trouvé. Découpez-la en trois ou quatre couches et voyez si les relectures reviennent plus vite.

Le chiffre de 9 % est une affirmation de GitHub sur son propre produit. Vos propres délais de relecture, avant et après, sont le chiffre qui mérite d'être suivi.