Une pile est une série de demandes d’extraction dans le même référentiel où chaque demande de tirage cible la branche de la demande de tirage sous celle-ci, formant une chaîne ordonnée qui atterrit sur une branche unique, généralement votre branche principale. Au lieu d’une demande de tirage volumineuse, vous obtenez un ensemble de demandes de tirage plus petites. Étant donné que chaque demande de tirage a ses propres différences ciblées, les collègues peuvent examiner et approuver chaque couche indépendamment.
Chaque pull request d’une pile est évaluée par rapport aux règles pour la base de la pile — généralement main — quelle que soit la branche qu’elle cible directement. Cela signifie que les pull requests intermédiaires sont soumises au même niveau d’exigence que la pull request du bas.
Remarque
- Les demandes de tirage empilées nécessitent que toutes les branches se soient dans le même référentiel. Les piles inter-fourche ne sont pas prises en charge.
- Les demandes de tirage empilées ne sont pas prises en charge dans GitHub Desktop.
Disponibilité des pull requests empilées
L’extension gh stackGitHub CLI gère le flux de travail de développement local. Il crée et effectue le suivi des branches dans l’ordre de dépendance approprié, maintient les branches rebasées, envoie (push) des branches, crée et lie des pull requests, et navigue entre les couches.
GitHub CLI n’est pas obligatoire. Les opérations Git sous-jacentes sont standard et vous pouvez créer des piles depuis le site web GitHub à la place.
Si vous utilisez d’autres outils, tels que Jujutsu ou Sapling, pour gérer et envoyer (push) vos branches locales, vous pouvez toujours utiliser GitHub CLI ou le site web GitHub pour ouvrir une série de pull requests à partir de ces branches. Consultez « Utiliser d’autres outils avec des pull requests empilées ».
Trunks pour les pull requests empilées
Le tronc d’une pile est la branche de base de la pull request du bas. Toutes les autres pull requests dans la pile sont basées dessus. Le trunk correspond par défaut à la branche par défaut de votre référentiel, par exemple main, mais il peut s’agir de n’importe quelle branche, telle qu’une branche de mise en production ou une branche de fonctionnalité de longue durée.
Pour définir le trunk :
- À partir de GitHub CLI passez l’option
--base BRANCHà la commandegh stack init(par exemple,gh stack init --base release auth-layer). - À partir du GitHub site web, créez la pull request du bas par rapport à la branche que vous souhaitez utiliser comme tronc. Le reste de la pile s’appuie dessus.
Les règles de protection des branches, les vérifications requises et l’intégration continue sont toutes évaluées par rapport à la branche trunk ciblée par la pile, pas seulement par rapport à votre branche par défaut.
Protections des branches et vérifications requises
Les éléments suivants sont tous évalués comme si chaque pull request cible la base de la pile, et non la branche directement en dessous :
| Rule | Comment elle est évaluée |
|---|---|
| Révisions requises | Évalué par rapport à la base de la pile. |
| Vérifications d’état requises | Évalué par rapport à la base de la pile. |
| CODEOWNERS | Évalué à partir de la base de la pile. Modifications apportées à CODEOWNERS dans une pull request inférieure, mais n’affecte pas les pull requests supérieures. |
| Flux de travail d’analyse du code | Évalué par rapport à la base de la pile. |
GitHub Actions
GitHub Les workflows Actions se déclenchent comme si chaque pull request dans la pile cible la base de la pile. Un flux de travail configuré pour s’exécuter sur des événements pull_request ciblant main s’exécute pour chaque pull request dans la pile, pas seulement celle du bas, donc aucune modification du flux de travail n’est requise.
Les métadonnées de pile, telles que la branche de base de la pile, sont disponibles dans les expressions de flux de travail via github.event.pull_request.stack. Cette propriété est présente uniquement lorsque la pull request appartient à une stack.
Pour obtenir l’ensemble complet de champs de métadonnées et de schémas afin de réduire l’utilisation redondante de CI, consultez Optimisation de la CI pour les pull requests empilées.
Rebase
Lorsqu’un rebase est disponible ou nécessaire, la zone de fusion indique cela en affichant un bouton Rebase stack. Par exemple, cela peut se produire lorsque les modifications apportées à une pull request rendent la pile non linéaire. Lorsque la pull request du bas est fusionnée, une rebase se produit automatiquement et vous n’aurez généralement pas besoin de rebaser manuellement.
Lorsqu’une pile est rebasée, vous pouvez vous attendre à ce qui suit :
- Le fait de rebaser la pile génère des commits signés.
- La rebasation d’une pile ne compte pas comme un nouveau commit pouvant être examiné si la différence ne change pas. Les approbations sont conservées dans cette situation, même lorsque la règle Ignorer les approbations obsolètes de pull request lorsque de nouveaux commits sont poussés est activée.
Exigences pour la fusion
Avant qu’une pull request dans une stack puisse fusionner, toutes les conditions suivantes doivent être satisfaites :
- La pull request répond à chaque exigence de protection de branche pour la stack base, y compris les révisions obligatoires, les vérifications de statut requises et les approbations de CODEOWNER.
- Toutes les pull requests ci-dessous dans la pile répondent également à ces exigences.
- La pile a un historique entièrement linéaire entre ses branches.
Par exemple, dans la pile main ← PR1 ← PR2 ← PR3, la fusion de la PR #3 nécessite également que les PR #1 et #2 réussissent les vérifications, aient les révisions requises et satisfassent à toutes les règles de protection de branche.
Remarque
Les pull requests empilées prennent en charge la fusion avec les règles de contournement, mais seule la pull request du bas peut être fusionnée de cette façon. Vous ne pouvez pas fusionner l’ensemble de la pile avec des règles de contournement. Consultez Création d'ensembles de règles pour un dépôt
Méthodes de fusion
Les stacks prennent en charge les trois méthodes de fusion. Dans chaque cas, les pull requests sont fusionnées en une seule opération atomique :
- Commit de fusion crée un commit de fusion pour chaque pull request en cours de fusion, en conservant l’historique complet de chaque pull request.
- Squash crée un commit squash propre par pull request. La fusion des pull requests
ncréendes commits squashés sur la branche de base. - Rebase rejoue les commits de chaque pull request sur la branche de base, en créant un historique linéaire sans commits de fusion.
Fusion via la file de fusion
Stacks prennent entièrement en charge les files d’attente de fusion. Toutes les demandes de fusion dans la pile sont ajoutées à la file d’attente dans l’ordre correct. Si une pull request est supprimée ou éjectée de la file d’attente, toutes les pull requests au-dessus d’elle dans la pile sont également supprimées.
Remarque
Pour maintenir une pile groupée, la file d’attente de fusion permet au groupe de fusion de dépasser sa taille maximale configurée jusqu’à 50 %. Si la pile est trop grande pour s’adapter à cette mémoire tampon, elle sera automatiquement placée dans le groupe de fusion suivant en tant qu’unité unique.
Historique linéaire
Un historique entièrement linéaire entre chaque branche de la pile est une exigence stricte pour la fusion. Une stack peut perdre son historique linéaire lorsque les modifications sont poussées vers une branche inférieure ou lorsque la branche principale avance.
Pour restaurer un historique linéaire, exécutez une rebase en cascade :
- À partir de la CLI, exécutez
gh stack rebase, puis envoyez (push) avecgh stack push. - À partir du GitHub site web : cliquez sur Rebase stack dans la zone de fusion pour déclencher une rebase en cascade côté serveur.
Pour les instructions, consultez Gestion des pull requests empilées.