GitHub stacked PR : un petit diff n'est pas une unité de déploiement
Diviser un changement en trois PR raccourcit la lecture. Une PR dépendant de celle du dessous n'est pourtant pas déployable seule.
L'annonce du 6 octobre
GitHub a annoncé la disponibilité générale le 6 octobre 2026. Les petites PR peuvent être revues séparément puis fusionnées ensemble, sur tous les forfaits github.com.
Une pile entre dans la merge queue comme un seul merge group. Avec la méthode merge commit, un commit est créé par PR. L'unité testée diffère donc de celle de l'historique.
Définir le périmètre de revue
A ajoute une fonction, B l'utilise dans une API, C crée l'interface. Notez dépendances et base de comparaison. C'est une proposition de méthode, pas une garantie automatique du produit.
Lire uniquement B peut masquer une vérification d'autorisation oubliée dans A. Séparez revue de chaque diff et validation de A+B+C, avec un responsable d'intégration.
Lire les approbations après rebase
GitHub conserve les approbations lors du rebase d'une pile autrement inchangée après un déplacement de sa base, même avec rejet des anciennes approbations. Approbation et preuve d'intégration restent distinctes.
Conservez les SHA avant et après rebase et le merge group testé. Vérifiez la nouvelle exécution des tests et la combinaison couverte par leurs journaux ; une coche verte seule ne suffit pas.
Séparer fusion et déploiement
Si fonction et API doivent partir ensemble, gardez cette dépendance dans le plan de déploiement. Un commit par PR ne rend pas sûr le rollback isolé si des appelants restent.
Des correctifs indépendants n'ont pas besoin d'une pile. Les regrouper peut faire attendre tout le monde sur un test retardé : c'est un compromis opérationnel.
GA et disponibilité réelle
GitHub prévoit le déploiement d'auto-merge dans les prochaines semaines. Vérifiez les commandes réellement visibles plutôt que de supposer un bouton identique pour tous dès aujourd'hui.
Les retours de preview ont guidé des améliorations de navigation et d'automatisation. Ils signalent un intérêt, pas une productivité garantie. Mesurez votre attente de revue et vos échecs d'intégration.
Tester une petite pile
Choisissez deux PR clairement dépendantes, par exemple fonction et appelant. Documentez base, dépendance et commandes de test ; convenez de la responsabilité d'intégration et du rollback.
Comparez le temps gagné aux éventuels nouveaux échecs. Si entretenir la pile coûte davantage, revenez aux PR ordinaires. Une revue et un déploiement plus clairs comptent plus que le nombre de diffs.
Sources officielles
Annonce du 6 octobre ; vérification le 8 octobre 2026. Contrôlez règles et fonctions disponibles avant adoption.