# À propos des demandes de tirage empilées Décomposez les modifications de code volumineuses en une chaîne de demandes de tirage plus petites et dépendantes que vous pouvez examiner et fusionner indépendamment. > \[!NOTE] Cette fonctionnalité est disponible en préversion publique et peut être modifiée. ## À propos des demandes de tirage empilées Les demandes de tirage empilées sont deux ou plusieurs demandes de tirage dans le même référentiel, où : * La première, ou la partie inférieure, cible la jonction de la pile , généralement la branche par défaut de votre dépôt, par `main`exemple, même si elle peut être n’importe quelle branche, telle qu’une branche de mise en production. * Chaque demande de tirage suivante cible la branche de la demande de tirage sous celle-ci. ```text ┌── feat/frontend → PR #3 (base: feat/api-endpoints) ← top ┌── feat/api-endpoints → PR #2 (base: feat/auth-layer) ┌── feat/auth-layer → PR #1 (base: main) ← bottom main (default base branch) ``` Les branches empilées forment une chaîne de dépendances, où chaque branche s’appuie sur celle-ci. Les modifications fondamentales telles que les types partagés et le schéma de base de données vont dans les branches inférieures, et le code qui en dépend, tels que les itinéraires d’API et les composants de l’interface utilisateur, vont dans des branches supérieures. Chaque demande de tirage dans une pile représente une modification discrète et modifiable d’une ou plusieurs validations. Vous pouvez examiner et itérer sur chaque demande de tirage indépendamment, et chacun affiche uniquement les différences de sa couche et les modifications entre sa branche et la branche située en dessous. **Principe clé :** si le code d’une couche dépend du code d’une autre, la dépendance doit se trouver dans la même branche ou une branche inférieure. Créez une branche lorsque vous démarrez une autre préoccupation qui dépend de ce que vous avez créé jusqu’à présent. Par exemple, lorsque vous passez du serveur principal au travail frontal, passez de la logique principale aux tests ou lorsque la branche actuelle est déjà assez grande pour passer en revue. ## Pourquoi utiliser GitHub des demandes de tirage empilées ### Terminer un changement et passer directement à la suivante Les demandes de tirage empilées vous permettent d’ouvrir une nouvelle demande de tirage au-dessus d’une demande qui est toujours ouverte. Pendant un projet volumineux, votre prochaine modification peut dépendre du travail qui n’a pas encore été fusionné. Au lieu d’attendre qu’elle se fusionne, avec une pile, vous pouvez continuer à générer. Avec chaque demande de tirage dans une pile contenant une modification ciblée, les réviseurs voient un petit différences pour chaque couche au lieu de la demande de tirage volumineuse. Les demandes de tirage plus petites sont plus rapides à examiner, moins susceptibles d’être ignorées et moins susceptibles d’être obsolètes et de développer des conflits de fusion. ### Adapté au développement en volume élevé Lorsque vous générez un grand nombre de code à la fois, souvent avec des agents IA, une pile donne à chaque modification un endroit où aller. Un agent effectue une tâche, puis démarre la tâche suivante qui s’appuie dessus. Cette séquence est mappée directement sur une pile : une demande de tirage par tâche, chacune basée sur celle ci-dessous. Les piles vous permettent d’enregistrer ces dépendances explicitement au lieu de combiner des modifications non liées en une seule branche. ### Avantages de l’utilisation de demandes de tirage empilées dans GitHub Sans demandes de tirage empilées, cassant un changement important en demandes de tirage plus petites, les demandes de tirage dépendantes créent un travail supplémentaire : * **Gestion des branches.** Le rebasage et la synchronisation des branches entre les demandes de tirage dépendantes sont fastidieuses et sujettes aux erreurs. * **Règles et CI.** Les règles de protection des branches et CI vérifient souvent uniquement le déclenchement de la demande de tirage inférieure dans la chaîne, ce qui rend difficile de connaître le véritable état du reste. * **Passez en revue le contexte.** L’examen d’un seul changement de contexte par rapport au reste de la pile peut réduire la qualité de l’examen. Les demandes de tirage empilées résolvent ces problèmes en traitant la chaîne de demandes d’extraction comme une unité connectée tout en conservant chaque couche petite et ciblée. #### Rebasing La rebasing est la partie la plus délicate de l’utilisation des piles et GitHub la gère automatiquement. Vous pouvez déclencher une rebase en cascade côté serveur à partir de la requête pull ou exécuter une rebase en cascade locale avec l’extension `gh stack` dans GitHub CLI. Lorsque vous fusionnez une demande de tirage en bas de la pile, les branches restantes sont automatiquement redéployées afin que la requête pull suivante cible la branche de base par défaut. ## Où pouvez-vous utiliser des demandes de tirage empilées Les demandes de tirage empilées sont disponibles dans les éléments suivants : * GitHub CLI * Site web GitHub * GitHub Mobile * Prise en charge programmatique par le biais de Webhooks, d’API REST et de GraphQL * Pour les agents, via la `gh-stack` compétence > \[!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. ### Dans GitHub CLI L’extension `gh stack` dans GitHub CLI gère le flux de travail de développement local. Vous pouvez créer et suivre les branches dans l’ordre de dépendance approprié, conserver les branches rebase, les branches push, créer et lier des demandes de tirage, et naviguer entre les couches. Consultez « [Commandes CLI des demandes de tirage empilées](/fr/enterprise-cloud@latest/pull-requests/reference/stacked-prs-cli-commands) ». ### Sur le GitHub site web Quand une demande de tirage fait partie d’une pile, vous verrez : * Icône de pile en haut de la demande de tirage avec un nombre indiquant la couche que vous affichez. * Une carte de pile s’affiche dans la zone de fusion. Il affiche chaque demande de tirage dans la pile et son état, et vous permet d’accéder à n’importe quelle couche en un clic. La jonction (branche de base par défaut) se trouve en bas, chaque demande de tirage dans la pile ciblant la branche de la demande de tirage en dessous. ### Prise en charge programmatique par le biais de Webhooks, d’API REST et de GraphQL Les demandes d’extraction empilées sont disponibles par programmation. Vous pouvez donc les intégrer à vos propres outils, automatisation et tableaux de bord : * **Les webhooks** incluent un `stack` objet dans `pull_request` des charges utiles d’événement, afin que votre automatisation puisse répondre lorsqu’une demande de tirage joint, se déplace ou quitte une pile. * **L’API REST** lit l’appartenance à la pile d’une demande de tirage et fournit des points de terminaison pour répertorier, créer, étendre et dissolutionr des piles. * **L’API GraphQL** expose des champs en lecture seule `stack` sur une demande de tirage pour interroger la pile et la position de la requête pull dans celle-ci. ## Règles, CI et fusion ### Règles et application ci Les demandes de tirage empilées prennent en charge les flux de travail GitHub Actions . Les exigences de fusion pour toute demande de tirage dans la pile sont déterminées par la branche de base de la demande de tirage inférieure, généralement `main`. * Les règles de protection de branche, telles que les approbations CODEOWNER, sont appliquées à chaque demande de tirage dans la pile, même les demandes d’extraction intermédiaires qui ne ciblent pas directement votre branche par défaut. * Les vérifications CI déclenchées par les demandes de tirage sur votre branche par défaut s’exécutent pour toutes les demandes de tirage dans la pile, et non pas seulement dans le bas. Cela garantit que chaque couche de la pile répond à la même barre de qualité avant de pouvoir fusionner. ### Fusion Vous pouvez fusionner l’ensemble de votre pile, une demande de tirage unique ou une partie de la pile couvrant plusieurs demandes de tirage. La pile entière n’a pas besoin de fusionner à la fois, mais les demandes de tirage doivent être fusionnées à partir du bas vers le haut. * Fusionnez la pile entière à la fois en fusionnant la demande de tirage supérieure. Chaque demande de tirage ci-dessous est fournie avec elle. * Fusionnez une partie de la pile en fusionnant une demande de tirage intermédiaire. Les demandes de tirage ci-dessous sont également fusionnées, et les demandes de tirage ci-dessus restent ouvertes et ciblent automatiquement la branche de base de la pile. Les piles prennent en charge la validation de fusion, la courge et la rebase des méthodes de fusion, et elles prennent en charge la file d’attente de fusion. L’historique de validation résultant est identique à la fusion de chaque demande de tirage individuellement, en commençant par le bas. > \[!NOTE] > Si vous fusionnez via l’API et que vous souhaitez utiliser des demandes de tirage empilées, vous devez effectuer une mise à jour pour utiliser la nouvelle API de fusion pour les piles. Consultez « [Points de terminaison d’API REST pour les pull requests](/fr/enterprise-cloud@latest/rest/pulls/pulls?apiVersion=2026-03-10#merge-a-pull-request-asynchronously) ». ## Étapes suivantes * [Démarrage rapide pour les demandes de tirage empilées](/fr/enterprise-cloud@latest/pull-requests/get-started/stacked-prs-quickstart?utm_source=docs-pr-stacks-quickstart\&utm_medium=docs\&utm_campaign=stacked-prs-gtm-public-preview-2026) * [Déployer des demandes de tirage empilées dans votre organisation](/fr/enterprise-cloud@latest/pull-requests/tutorials/roll-out-stacked-prs?utm_source=docs-roll-out-pr-stacks\&utm_medium=docs\&utm_campaign=stacked-prs-gtm-public-preview-2026)