Pourquoi vos PRs sont un goulot d'étranglement
Les Mega-PRs paralysent la vélocité de développement. Réviser des centaines, voire des milliers de lignes de code devient une tâche impossible, entraînant des bugs ignorés, des revues superficielles et une fatigue intense des réviseurs. Ces changements monolithiques empêchent les autres développeurs d'intégrer leur travail, créant des goulots d'étranglement généralisés.
Conséquence : escalade des conflits de fusion, branches de code rapidement obsolètes et retards de publication considérables. Ce cycle inefficace gaspille d'innombrables heures d'ingénierie, introduit un risque significatif dans la base de code et frustre les équipes de développement par sa complexité inhérente.
GitHub propose désormais les Stacked PRs, une réponse officielle et native à ce problème persistant. Cette fonctionnalité robuste va au-delà des solutions de contournement communautaires ad hoc, en intégrant une gestion puissante des dépendances directement dans votre workflow.
Le concept de base est simple : divisez les changements de code importants en une chaîne de pull requests plus petites et interdépendantes. Chaque PR s'appuie directement sur la précédente, permettant une revue, une approbation et une fusion indépendantes sans bloquer l'ensemble de la fonctionnalité.
Illustrez cette chaîne de dépendance : votre PR fondamentale initiale cible main — par exemple, une migration critique du schéma de base de données. Ensuite, une deuxième PR cible cette première PR, implémentant de nouvelles routes API dépendantes du schéma mis à jour. Enfin, une troisième PR cible la deuxième PR, ajoutant des composants UI consommant la nouvelle API. Cela crée une progression claire, logique et gérable pour les fonctionnalités complexes.
Votre nouveau workflow : Stack, Add, Submit
Implémentez les stacked PRs en utilisant le GitHub CLI pour un workflow rationalisé et efficace. Initiez votre nouvelle pile avec gh stack init [branch-name]. Cette commande établit votre branche fondamentale, en la basant automatiquement sur la branche par défaut de votre dépôt, généralement main. Cela garantit que vos changements de plus bas niveau sont prêts en premier.
Faites progresser votre développement de manière incrémentale en ajoutant d'autres changements. Utilisez gh stack add [branch-name] pour créer une nouvelle branche qui se base automatiquement sur la précédente branche de votre pile. Cela établit une chaîne de dépendance claire, garantissant que chaque changement ultérieur se construit logiquement sur le précédent, des types fondamentaux aux routes API.
Il est crucial de noter que les opérations Git standard persistent sous cette commodité du CLI. Chaque commande gh stack add crée finalement une nouvelle branche Git, et vous conservez la flexibilité d'inclure plusieurs commits au sein de n'importe quelle branche de votre pile. Cela offre un développement structuré sans sacrifier le contrôle granulaire sur l'historique des commits.
Lorsque tous les changements sont terminés dans votre pile, consolidez vos efforts avec une seule commande : gh stack submit. Cela pousse simultanément chaque branche de votre pile vers GitHub, générant des pull requests individuelles pour chacune. GitHub les affiche ensuite sous forme de stacked PR cohérente dans l'interface utilisateur, simplifiant ainsi la revue.
Bien que le GitHub CLI offre une automatisation et une commodité puissantes, ce n'est pas un prérequis strict. Les développeurs peuvent toujours construire manuellement des piles en s'assurant que chaque pull request cible explicitement la branche de base précédente correcte. GitHub détecte et visualise intelligemment ces dépendances, même sans orchestration CLI, offrant les mêmes avantages d'interface et la même expérience de revue.
Au-delà du CLI : les Stacks en pratique
GitHub améliore les stacked PRs avec une interface utilisateur de premier ordre. Remarquez l'icône de pile distincte désormais présente sur la page de liste des pull requests, signalant instantanément qu'une PR fait partie d'une chaîne de dépendances plus large. Cet indicateur visuel simplifie l'identification et la gestion du travail interconnecté, améliorant la visibilité globale du projet.
Plongez dans n'importe quelle PR au sein d'une pile pour tirer parti de la vue de pile dédiée. Cette interface puissante visualise toute la chaîne de dépendances, cartographiant clairement la position de chaque PR, sa branche cible et son statut de révision actuel. Vous obtenez une clarté immédiate sur les ensembles de fonctionnalités complexes, comprenant les dépendances et la progression en un coup d'œil. Pour plus de détails fondamentaux sur le travail avec les pull requests et leurs nouvelles capacités de pile, consultez About stacked pull requests - GitHub Docs.
La véritable efficacité arrive avec le bouton Merge stack. Une fois que toutes les PR individuelles d'une pile ont été approuvées, un seul clic fusionne toute la chaîne approuvée dans la branche principale. GitHub exécute automatiquement la fusion séquentielle, gérant toutes les étapes intermédiaires telles que le rebasage et les mises à jour de branche. Cette opération atomique garantit une fusion propre et intégrée sans intervention manuelle, accélérant votre pipeline de livraison et minimisant les conflits de fusion.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
Les piles ne sont pas réservées aux humains
Des diffs plus petits et ciblés débloquent immédiatement les réviseurs, accélérant considérablement les cycles de révision. Une réduction du changement de contexte et de la charge cognitive signifie des approbations plus rapides et des retours de meilleure qualité. Les équipes itèrent désormais plus rapidement, déployant des fonctionnalités avec une efficacité sans précédent.
Au-delà des flux de travail humains, les Stacked PRs ouvrent un avenir puissant pour l'IA. Les agents d'IA peuvent désormais soumettre des fonctionnalités complexes en plusieurs parties sous forme de pull requests structurées et dépendantes. Cela décompose le code monolithique généré par l'IA en morceaux gérables et révisables. Au lieu d'un seul énorme dépôt de code, les agents produisent une chaîne de dépendances révisable par l'humain, offrant un chemin clair et vérifiable pour intégrer des contributions d'IA sophistiquées.
Cette fonctionnalité est plus qu'une optimisation du flux de travail ; elle représente un changement fondamental dans les pratiques de développement collaboratif. Elle redéfinit fondamentalement la manière dont les équipes abordent la livraison de fonctionnalités complexes et le travail simultané. La réponse des développeurs a été extrêmement positive, validant la vision de GitHub pour l'évolution du développement de base. Attendez-vous à des gains immédiats et significatifs en termes de vélocité d'équipe et de débit global du projet.
Questions fréquemment posées
Que sont les GitHub Stacked PRs ?
Une fonctionnalité native de GitHub pour créer une chaîne de pull requests plus petites et dépendantes qui peuvent être révisées indépendamment et fusionnées ensemble en une seule unité.
Ai-je besoin du GitHub CLI pour utiliser les Stacked PRs ?
Non. Le CLI (avec les commandes gh stack) simplifie le processus, mais vous pouvez créer une pile manuellement en ciblant les PR suivantes sur la branche de la PR précédente. GitHub détecte automatiquement la pile.
En quoi une pile est-elle différente du simple chaînage de PRs ?
Bien que le concept Git soit similaire, GitHub reconnaît désormais officiellement ces chaînes comme une « pile ». Cela fournit une interface utilisateur dédiée pour gérer, visualiser et fusionner toute la pile en une seule fois, ce qui était auparavant un processus manuel.
Puis-je travailler sur d'autres branches pendant que j'ai une pile active ?
Oui. Une pile est une couche de gestion au-dessus de Git. Vous pouvez utiliser des commandes Git standard comme git checkout pour basculer vers des branches non liées, puis revenir à une branche au sein de votre pile plus tard sans problème.