Pull requests empilées ou une seule grosse pull request : quelle forme de revue pour le code généré par IA ?
Pull requests empilées ou une grosse PR : taille de revue, coût du rebase, commits signés et agents, chiffres 2026.
Choisissez les pull requests empilées lorsque votre goulot d'étranglement est la capacité de revue et que le changement présente des couches naturelles. C'est désormais le cas courant : le directeur technique de TED décrit exactement ce mécanisme dans l'annonce de GitHub — l'IA a rendu les développeuses et développeurs nettement plus productifs, et la nouvelle contrainte est devenue des pull requests si volumineuses que les relecteurs peinaient. Les données soutiennent l'unité plus petite : une analyse de 1,5 million de pull requests citée au lancement montre que celles comptant de 200 a 400 lignes modifiées présentaient 40 % de défauts en moins et étaient approuvées trois fois plus vite que les plus grosses. Une pile est précisément le mécanisme qui maintient chaque pull request dans cette fourchette, même pour une fonctionnalité conséquente. Choisissez une pull request unique lorsque le changement ne porte réellement que sur un seul sujet, lorsque votre dépôt exige des commits signés et que l'équipe n'empruntera pas de manière fiable le chemin local gh stack rebase, ou lorsque la fonctionnalité demanderait plus de trois ou quatre couches. Ce plafond n'est pas arbitraire : la pratique rapporte trois a quatre pull requests par pile, au-delà desquelles le suivi des dépendances coûte plus d'attention que les diffs réduits n'en font gagner. Une pile de cinq couches que personne ne rebase correctement vaut moins qu'un gros diff assumé. Le facteur décisif n'est pas la maturité de l'outillage mais l'identité de qui écrit le code. Un agent entraîné sur dix ans de pull requests monolithiques produira une pull request monolithique tant que vous ne lui direz pas autre chose, et découper après coup un diff terminé de 1 700 lignes est nettement plus pénible que de le construire en couches. Installez la compétence d'agent, donnez à chaque couche un périmètre défini et une personne responsable, et la décomposition se produit au moment de l'écriture, là où elle coûte peu. Sautez cette étape et les pull requests empilées ne sont plus que des branches supplémentaires à rebaser. La forme de la revue doit être une contrainte imposée a l'agent, pas une tâche de nettoyage laissée a l'humain.
Comparaison Détaillée
Une analyse comparative des facteurs clés pour vous aider à faire le bon choix.
| Facteur | Pull requests empiléesRecommandé | Une seule grosse pull request | Gagnant |
|---|---|---|---|
| Taille de l'unité soumise a la revue | Chaque couche ne porte que sur un seul sujet et reste dans la fourchette de 200 à 400 lignes modifiées, là où la revue est mesurablement la plus efficace. | La fonctionnalité entière arrive en un seul diff ; l'exemple de GitHub compte 1 721 lignes modifiées avant décomposition. | |
| Répartition des relecteurs | La couche de données est relue par la personne responsable des données, l'interface par celle qui la maîtrise, et les couches se relisent en parallèle. | Une seule personne doit tenir en tête le modèle de données, le contrat d'API, le raccordement client et les états d'interface en même temps. | |
| Délai de retour | La couche un peut être relue, corrigee et approuvee pendant que la couche quatre s'écrit encore. | Rien n'est relisible avant que la fonctionnalité entière soit terminée : tous les retours arrivent a la fin. | |
| Cout d'une modification sur une couche basse | Une correction en bas impose un rebase en cascade de toutes les branches supérieures ; gh stack sync automatise la cascade, mais le rebase reste un vrai travail. | Une branche, un rebase, aucune chaîne de dépendances a réparer quand un retour arrive. | |
| Mécanique de fusion | Fusionnez toute la pile en une opération, ou intégrez les couches basses et laissez les pull requests supérieures se rebaser et se recibler automatiquement. | Une fusion unique, sans état de pile à interpréter ni décision d'intégration partielle. | |
| Commits signés et protection de branche | Le bouton de rebase dans le navigateur s'exécute sur les serveurs de GitHub, réinitialise l'auteur du commit et produit des commits non signés, ce qui casse la protection exigeant des commits signés ; gh stack rebase en local l'evite. | Aucun rebase en cascade, donc aucun auteur réinitialise ni signature perdue a surveiller. | |
| Plafond de mise a l'échelle | La pratique situe la limite utile à trois ou quatre couches ; au-delà, le suivi des dépendances pèse plus lourd que le gain de revue. | Aucune limite structurelle de taille, mais la qualité de la revue et l'attention du relecteur déclinent a mesure que le diff grossit. | |
| Adéquation aux agents de codage | La compétence d'agent de gh-stack apprend aux agents à découper le travail en couches ordonnées pendant l'écriture : la forme devient une contrainte et non une reprise. | Entraînés sur dix ans de pull requests monolithiques, les agents produisent par défaut un gros diff, et le découper après coup est plus pénible que de construire en couches d'emblée. | |
| Score Total | 4/ 8 | 2/ 8 | 2 égalités |
Statistiques Clés
Données réelles provenant de sources vérifiées du secteur pour appuyer votre décision.
GitHub Engineering Blog
InfoQ
Gartner, cite par GitHub Engineering
API REST GitHub, github/gh-stack
GitHub Changelog
Alan West, cite par InfoQ
Toutes les statistiques proviennent de sources tierces vérifiées. La source, l'année et le lien direct sont affichés pour chaque chiffre.
Quand Choisir Chaque Option
Un guide clair basé sur votre situation spécifique et vos besoins.
Choisissez Pull requests empilées quand...
- Le changement se découpe naturellement en couches dépendantes — données, API, raccordement, interface — avec des responsables distincts.
- Un agent de codage a produit un diff que vous ne pouvez honnêtement pas relire en une seule séance.
- Votre goulot d'étranglement est la capacité de revue, pas la vitesse d'écriture.
- Vous voulez faire relire et intégrer la couche de base pendant que les couches supérieures s'ecrivent encore.
Choisissez Une seule grosse pull request quand...
- Le changement ne porte réellement que sur un seul sujet et reste sous quelques centaines de lignes modifiées.
- Votre dépôt exige des commits signés et l'équipe n'empruntera pas de manière fiable le chemin local gh stack rebase.
- La fonctionnalité demanderait plus de trois ou quatre couches, là où la charge des dépendances dépasse le gain de revue.
- Votre équipe n'a pas d'outillage compatible avec les piles et devrait entretenir la chaîne de branches a la main.
Notre Recommandation
Choisissez les pull requests empilées lorsque votre goulot d'étranglement est la capacité de revue et que le changement présente des couches naturelles. C'est désormais le cas courant : le directeur technique de TED décrit exactement ce mécanisme dans l'annonce de GitHub — l'IA a rendu les développeuses et développeurs nettement plus productifs, et la nouvelle contrainte est devenue des pull requests si volumineuses que les relecteurs peinaient. Les données soutiennent l'unité plus petite : une analyse de 1,5 million de pull requests citée au lancement montre que celles comptant de 200 a 400 lignes modifiées présentaient 40 % de défauts en moins et étaient approuvées trois fois plus vite que les plus grosses. Une pile est précisément le mécanisme qui maintient chaque pull request dans cette fourchette, même pour une fonctionnalité conséquente. Choisissez une pull request unique lorsque le changement ne porte réellement que sur un seul sujet, lorsque votre dépôt exige des commits signés et que l'équipe n'empruntera pas de manière fiable le chemin local gh stack rebase, ou lorsque la fonctionnalité demanderait plus de trois ou quatre couches. Ce plafond n'est pas arbitraire : la pratique rapporte trois a quatre pull requests par pile, au-delà desquelles le suivi des dépendances coûte plus d'attention que les diffs réduits n'en font gagner. Une pile de cinq couches que personne ne rebase correctement vaut moins qu'un gros diff assumé. Le facteur décisif n'est pas la maturité de l'outillage mais l'identité de qui écrit le code. Un agent entraîné sur dix ans de pull requests monolithiques produira une pull request monolithique tant que vous ne lui direz pas autre chose, et découper après coup un diff terminé de 1 700 lignes est nettement plus pénible que de le construire en couches. Installez la compétence d'agent, donnez à chaque couche un périmètre défini et une personne responsable, et la décomposition se produit au moment de l'écriture, là où elle coûte peu. Sautez cette étape et les pull requests empilées ne sont plus que des branches supplémentaires à rebaser. La forme de la revue doit être une contrainte imposée a l'agent, pas une tâche de nettoyage laissée a l'humain.
Questions Fréquentes
Réponses aux questions courantes sur cette comparaison.
Besoin d'aide pour décider ?
Réservez une consultation gratuite de 30 minutes et nous vous aiderons à déterminer la meilleure approche pour votre projet spécifique.