# Demandes de tirage empilées Règles et exigences relatives à la façon dont les demandes de tirage empilées fonctionnent sur GitHub. > \[!NOTE] Cette fonctionnalité est disponible en préversion publique et peut être modifiée. 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 demande de tirage dans une pile est évaluée par rapport aux règles pour la **base de la pile** , `main` généralement, quelle que soit la branche qu’elle cible directement. Cela signifie que les demandes de tirage intermédiaires sont conservées dans la même norme que la demande de tirage inférieure. > \[!NOTE] > > * 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 demandes de tirage empilées L’extension `gh stack`GitHub 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é, conserve les branches rebase, envoie (push) des branches, crée et lie des demandes de tirage (pull request) 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 à partir du site web à la GitHub 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 GitHub site web pour ouvrir une pile de demandes de tirage à partir de ces branches. Consultez « [Utiliser d’autres outils avec des demandes de tirage empilées](/fr/enterprise-cloud@latest/pull-requests/reference/use-other-tools-with-stacked-pull-requests) ». ## Jonctions pour les demandes de tirage empilées La **jonction** d’une pile est la branche de base de la demande de tirage inférieure. Toutes les autres demandes de tirage dans la pile sont basées dessus. La jonction par défaut est la branche par défaut de votre référentiel, par `main`exemple, mais elle peut être n’importe quelle branche, telle qu’une branche de mise en production ou une branche de fonctionnalité de longue durée. Pour définir la jonction : * **De GitHub CLI** passez l’option `--base BRANCH` à la `gh stack init` commande( par exemple). `gh stack init --base release auth-layer` * **À partir du GitHub site web** , créez la demande de tirage en bas sur la branche souhaitée comme jonction. 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 jonction cible de la pile, pas seulement par rapport à votre branche par défaut. ## Protections de branche et vérifications requises Les éléments suivants sont tous évalués comme si chaque demande de tirage 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` une demande de tirage inférieure, mais n’affecte pas les demandes de tirage au-dessus. | | Flux de travail d’analyse du code | Évalué par rapport à la base de la pile. | ## GitHub Actions GitHub Les workflows d’actions se déclenchent comme si chaque demande de tirage dans la pile cible la base de la pile. Flux de travail configuré pour s’exécuter sur `pull_request` les événements ciblant les `main` exécutions pour **chaque** demande de tirage dans la pile, pas seulement le bas, donc aucune modification de 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 demande de tirage appartient à une pile. Pour obtenir l’ensemble complet de champs et de modèles de métadonnées afin de réduire l’utilisation redondante de CI, consultez [Optimisation de l’intégration continue pour les demandes de tirage empilées](/fr/enterprise-cloud@latest/pull-requests/how-tos/merge-and-close-pull-requests/optimizing-ci-for-stacked-pull-requests). ## Exigences pour la fusion Avant qu’une demande de tirage dans une pile puisse fusionner, toutes les valeurs suivantes doivent être remplies : * La demande de tirage répond à chaque exigence de protection de branche pour la base de pile, y compris les révisions requises, les vérifications d’état requises et les approbations CODEOWNER. * **Toutes les demandes de tirage 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 pr #3 nécessite pr #1 et PR #2 pour transmettre également des vérifications, avoir des révisions requises et satisfaire à toutes les règles de protection de branche. ## Méthodes de fusion Les piles prennent en charge les trois méthodes de fusion. Dans chaque cas, les demandes d’extraction atterrissent en tant qu’opération atomique unique : * **La validation** de fusion crée une validation de fusion pour l’ensemble du groupe de demandes de tirage en cours de fusion, en préservant l’historique complet de chaque demande de tirage. * **Squash** crée une validation nettoyée et écrasée par demande de tirage. La fusion des demandes de `n` tirage crée `n` des validations écrasées sur la branche de base. * **Rebase** relecture les validations de chaque demande de tirage sur la branche de base, en créant un historique linéaire sans validations de fusion. ## Fusion via une file d’attente de fusion Les piles prennent entièrement en charge les files d’attente de fusion. Toutes les demandes de tirage dans la pile sont ajoutées à la file d’attente dans l’ordre correct. Si une demande de tirage est supprimée ou éjectée de la file d’attente, toutes les demandes de tirage au-dessus de la pile sont également supprimées. > \[!NOTE] > Pour conserver une pile ensemble, la file d’attente de fusion permet au groupe de fusion de dépasser sa taille maximale configurée de jusqu’à 50 %. Si la pile est trop grande pour s’adapter à cette mémoire tampon, elle est automatiquement répartie entre les groupes de fusion consécutifs. ## Historique linéaire Un historique entièrement linéaire entre chaque branche de la pile est une exigence stricte pour la fusion. Une pile peut perdre son historique linéaire lorsque les modifications sont poussées vers une branche inférieure ou lorsque la jonction avance. Pour restaurer un historique linéaire, exécutez une rebase en cascade : * **À partir de l’interface CLI** , exécutez `gh stack rebase`, puis envoyez (push) avec `gh 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 demandes de tirage empilées](/fr/enterprise-cloud@latest/pull-requests/how-tos/create-pull-requests/managing-stacked-pull-requests#rebasing-your-stack). ## Lectures complémentaires * [Déployer des demandes de tirage empilées dans votre organisation](/fr/enterprise-cloud@latest/pull-requests/tutorials/roll-out-stacked-prs)