PR empilées sur GitHub : des revues plus petites, une seule fusion

Ouvrez une pull request de 1 500 lignes modifiées et regardez ce qu'elle devient. Le relecteur lit les premiers fichiers avec soin, puis le diff continue, l'attention s'épuise, et le reste a droit à un défilement et à une approbation. Personne ne fait preuve de paresse : un gros diff demande plus de concentration qu'une seule séance n'en contient. Le 6 octobre 2026, GitHub a rendu les pull requests empilées (stacked pull requests) disponibles pour tous, et c'est précisément sa réponse à ce problème : découper un gros changement en une chaîne de petites pull requests, relues chacune pour elle-même, qui fusionnent quand même ensemble.

Pourquoi une grosse pull request finit tamponnée

En règle générale, l'attention d'un relecteur baisse à mesure que le diff grandit. Le premier fichier reçoit de vraies questions. Au quatorzième, on vérifie surtout que le code ressemble à du code. Le bug qui compte se trouve rarement dans le fichier que tout le monde jugeait risqué ; il est dans une petite modification d'un helper partagé, à mi-parcours, là où plus personne ne regardait. L'auteur paie aussi : une description de 1 500 lignes est difficile à écrire, alors elle dit souvent « voir le diff ».

La solution évidente, des pull requests plus petites, a toujours eu un coût. Si le deuxième morceau dépend du premier, soit vous attendez la fusion du premier pour ouvrir le deuxième, soit vous les ouvrez en chaîne et vous entretenez cette chaîne à la main.

Ce qu'est une pile, et ce que la GA a changé

Une pile est une chaîne de branches où chacune part de la précédente, et où chaque branche a sa propre pull request. La première ajoute une migration, la deuxième le service qui utilise la nouvelle colonne, la troisième l'endpoint qui appelle le service. Chacune est relue indépendamment, et la chaîne fusionne d'un bloc.

Le problème n'a jamais été l'idée. C'était ce qui arrivait quand quelqu'un demandait une modification dans la première pull request alors que la deuxième et la troisième étaient déjà relues : chaque branche au-dessus devait être rebasée à la main, et dans les dépôts qui invalident les approbations périmées, les revues du dessus partaient aussi à la poubelle. La version GA de GitHub s'attaque directement à ça. Son action « Rebase stack » conserve les approbations sur le code qui n'a pas changé, même dans les dépôts qui invalident les approbations périmées. Les commits rebasés restent signés, car GitHub crée des commits de remplacement signés et garde l'auteur d'origine.

Le reste de la version concerne l'atterrissage de la pile. Elle entre dans la merge queue et en sort comme un seul groupe de fusion, et avec la méthode par commit de fusion, GitHub crée un commit de fusion par pull request. Les permissions de contournement s'appliquent à la pull request non fusionnée la plus basse de la pile. Si une pile se ramifie et que sa branche de base est supprimée, les pull requests du dessus sont reciblées automatiquement au lieu que celle du bas soit fermée. L'auto-merge pour les piles, où chaque pull request d'un groupe choisi fusionne dès que toutes sont prêtes, se déploie au fil des semaines suivantes. Pour s'y retrouver, la pile apparaît dans l'en-tête de la pull request, Shift+J et Shift+K passent d'une pull request à l'autre, la timeline indique quand une pull request est ajoutée ou retirée, le webhook pull_request gagne une action stacked, et l'extension gh stack pour GitHub CLI fonctionne avec les worktrees Git.

GitHub a aussi publié des chiffres issus de la période de préversion : selon GitHub, les dépôts qui utilisent les piles ont fusionné 9 % de code de plus que les autres, et plus des deux tiers du top 1 % des dépôts utilisent désormais les piles et ont vu leur délai de fusion s'améliorer de 5 %. Lisez-les comme des mesures de GitHub sur sa propre fonctionnalité, pas comme une étude indépendante.

Si vous êtes le seul relecteur

Beaucoup de missions freelance et de projets en solo n'ont pas de second relecteur. La pile reste utile, pour des raisons générales qui n'ont rien à voir avec les chiffres de GitHub. Relire son propre diff de 200 lignes le lendemain matin attrape des choses que la relecture de son propre diff de 1 500 lignes n'attrapera jamais. On peut montrer au client l'étape deux qui fonctionne avant que l'étape trois existe. Quand quelque chose casse un mois plus tard, git bisect tombe sur un petit changement nommé au lieu d'un commit géant. Et si le développeur du client reprend le projet, il hérite d'un historique qu'il peut vraiment lire.

Quand ne pas empiler

Une pile a un coût, elle doit donc rapporter quelque chose. Passez-vous-en quand le changement est déjà assez petit pour être relu d'un coup. Passez-vous-en quand les morceaux ne peuvent pas être jugés séparément : si la première pull request n'a de sens qu'après avoir lu la troisième, c'est un seul changement, et le découper ne fait qu'étaler la confusion sur trois onglets. Méfiez-vous quand le bas de la pile bouge encore beaucoup, car chaque modification remonte vers le haut, et même avec les approbations conservées, les relecteurs du dessus lisent par rapport à une base mouvante. Enfin, une pile attend sa pull request la plus basse : dans une équipe où les revues prennent des jours, une pile de cinq étages peut traîner plus longtemps qu'une honnête pull request de taille moyenne.

La prochaine fois qu'une branche dépasse quelques centaines de lignes, arrêtez-vous avant d'ouvrir la pull request et notez les étapes qu'elle a réellement suivies. Chaque étape qu'un relecteur pourrait approuver seule est une pull request de la pile ; le reste va ensemble. Source : GitHub changelog, « Stacked pull requests generally available » (6 octobre 2026).