# Déployer des demandes de tirage empilées dans votre organisation

Planifiez et déployez des demandes de tirage empilées pour votre organisation, afin que vos équipes puissent expédier de grandes modifications en tant que petites couches modifiables sans compromettre vos règles et vérifications existantes.

> \[!NOTE]
> Les demandes de tirage empilées sont en préversion publique cours et peuvent être modifiées.

Les demandes de tirage empilées permettent aux développeurs d’interrompre les modifications importantes dans une chaîne de petites demandes de tirage ciblées qui s’appuient les unes sur les autres, ce qui facilite la révision, la fusion et l’expédition de chaque couche. Les demandes de tirage empilées donnent aux développeurs la possibilité de terminer un travail et de passer directement à la suivante sans attendre les révisions pour atterrir. Cela importe le plus quand le travail dépend naturellement de ce qui est venu avant elle, ce qui est courant quand une équipe travaille sur une grande version et chaque changement s’appuie sur le dernier.

Ce tutoriel vous guide tout au long de la préparation de votre organisation pour les demandes de tirage empilées : examen des considérations relatives au déploiement, compréhension de la façon dont vos règles de protection de branche et CI fonctionnent avec les piles et prise en main de vos équipes. Pour une compréhension fondamentale des demandes de tirage empilées, consultez [À propos des demandes de tirage empilées](/fr/pull-requests/get-started/about-stacked-prs).

## Prerequisites

Si votre équipe utilise déjà des demandes de tirage, vous êtes configuré pour utiliser des demandes de tirage empilées. Tout le reste de ce tutoriel est facultatif, mais suppose que votre organisation a :

* GitHub CLI, avec l’extension `gh-stack` installée. L’extension CLI est le moyen le plus complet de créer et de gérer des piles.
* Règles de protection de branche configurées pour votre branche par défaut.
* GitHub Actions flux de travail qui s’exécutent sur des demandes d’extraction ciblant votre branche par défaut.

Copilot n’est pas nécessaire pour utiliser des demandes de tirage empilées, mais elle est encouragée pour les équipes qui souhaitent empiler les modifications générées par l’IA. Les demandes de tirage empilées fonctionnent également avec d’autres agents de codage IA, tels que Claude Code et Codex, à l’aide de la compétence de l’agent fournie. Consultez « [Code généré par l’IA stack dans les demandes de tirage](/fr/copilot/tutorials/stack-ai-generated-code-in-pull-requests) ».

## 1. Examiner les considérations relatives au déploiement

Avant d’introduire des demandes de tirage empilées à vos équipes, passez en revue les considérations suivantes afin que tout le monde sache ce qu’il faut attendre.

### Les piles doivent être linéaires et ne peuvent pas inclure de fourche

Chaque demande de tirage dans une pile doit faire partie du même référentiel et s’appuyer sur une seule chaîne linéaire de branches. Les piles avec des structures de branchement ou des demandes de tirage à partir de fourche ne sont pas prises en charge. Si vos équipes s’appuient sur des fourche pour les contributions, prévoyez de conserver ces contributions en dehors des piles pour l’instant.

### Réorganiser une pile nécessite GitHub CLI

Si votre équipe doit réorganiser les demandes de tirage dans une pile, elles doivent être utilisées `gh stack modify` dans l’extension `gh stack`GitHub CLI . Il n’existe aucun moyen de réorganiser une pile à partir du GitHub site web. Les équipes qui n’utilisent pas l’interface CLI localement doivent planifier leur ordre de pile avec soin ou installer l’extension pour cette tâche.

### Impossible d’étendre une pile terminée

Une fois chaque demande de tirage dans une pile fusionnée, cette pile est fermée. Si une équipe ajoute de nouvelles branches en haut et s’exécute `gh stack submit`, l’interface CLI démarre une nouvelle pile avec la même branche de base. Les équipes qui souhaitent continuer à travailler sur une pile doivent planifier l’ouverture de la pile jusqu’à ce que tout le travail soit terminé.

## 2. Comprendre comment les règles de protection des branches et l’intégration continue fonctionnent avec les piles

Les demandes de tirage empilées sont conçues pour appliquer vos règles existantes de la même façon que n’importe quelle autre demande de tirage, mais il est utile de comprendre comment, étant donné que chaque demande de tirage dans une pile est évaluée un peu différemment de ce que vous pourriez vous attendre.

Chaque demande de tirage dans une pile, pas seulement la partie inférieure, est évaluée par rapport à **la base de la pile** (généralement `main`), plutôt que par rapport à la branche qu’elle cible directement. Cela signifie que :

* Les révisions requises, les vérifications d’état requises et CODEOWNERS sont toutes appliquées à la branche de base de la pile pour chaque demande de tirage dans la pile.
* Flux GitHub Actions de travail qui se déclenche sur `pull_request` les événements ciblant les `main` exécutions pour **chaque** demande de tirage dans la pile, de sorte que votre configuration CI existante n’a pas besoin de changer.
* Les métadonnées de pile sont disponibles dans les expressions de flux de travail via `github.event.pull_request.stack`, si vous souhaitez personnaliser le comportement du flux de travail spécifiquement pour les demandes de tirage empilées. Étant donné qu’un flux de travail s’exécute une fois par demande de tirage dans une pile, les équipes peuvent utiliser ces métadonnées pour ignorer les tâches coûteuses sur les exécutions redondantes et réduire l’utilisation de l’intégration continue. Pour plus d’informations, consultez [Optimisation de l’intégration continue pour les demandes de tirage empilées](/fr/pull-requests/how-tos/merge-and-close-pull-requests/optimizing-ci-for-stacked-pull-requests).

Si vous le souhaitez, vous pouvez voir cela en action en ouvrant une petite pile de tests sur un référentiel avec vos ensembles de règles standard et les vérifications requises en place, et en confirmant que :

1. Les révisions et les vérifications d’état sont requises sur chaque demande de tirage dans la pile, et pas seulement dans la partie inférieure.
2. Vos flux de travail CI s’exécutent sur chaque demande de tirage dans la pile.
3. La fusion est bloquée jusqu’à ce que la demande de tirage dans la pile que vous souhaitez fusionner, et tout ce qui se trouve en dessous, répond à vos besoins.

Pour obtenir la liste complète des règles et exigences, consultez [Demandes de tirage empilées](/fr/pull-requests/reference/stacked-pull-requests).

## 3. Prise en main de vos équipes

Une fois que vous avez examiné les considérations de déploiement et compris comment vos règles et ci fonctionnent avec les piles, pointez vos équipes sur AUTOTITLE, ce qui regroupe tout ce dont elles ont besoin pour commencer à créer, examiner et fusionner des demandes de tirage [empilées](/fr/pull-requests/how-tos/stacked-pull-requests).

## 4. Mettre à jour vos outils programmatiques

À mesure que votre organisation adopte des demandes de tirage empilées, passez en revue les outils internes, les bots ou les tableaux de bord qui créent, fusionnent ou effectuent le suivi des demandes de tirage par programmation, puis mettez-les à jour pour prendre en compte les piles.

> \[!IMPORTANT]
> La fusion d’une demande de tirage empilée nécessite l’API Stacks. Les points de terminaison de fusion de demande de tirage hérités ne peuvent pas fusionner une pile. Si votre organisation fusionne les demandes de tirage par programmation, par exemple par le biais d’outils internes ou de bots ChatOps, mettez à jour cet outil pour appeler l’API Stacks avant de déployer des demandes de tirage empilées.

Vous pouvez également suivre l’activité de pile par programme, par exemple, entre les tableaux de bord, les bots ou les outils internes.

* **API REST** : chaque demande de tirage retournée par l’API inclut un `stack` objet lorsqu’elle appartient à une pile, affichant le nombre, la taille de la pile, la position de la demande de tirage dans celle-ci et la branche de base de la pile. Une API Stacks dédiée (`GET /repos/{owner}/{repo}/stacks`) répertorie également chaque pile d’un référentiel ou la pile spécifique contenant une demande de tirage donnée. Consultez « [Requêtes de tirage empilées dans les API REST et GraphQL](/fr/pull-requests/reference/stacked-pull-requests-rest-and-graphql-apis) ».
* **Webhooks** : la `pull_request` charge utile du webhook inclut le même `stack` objet chaque fois qu’une demande de tirage appartient à une pile. Une action dédiée `stacked` se déclenche lorsqu’une demande de tirage est ajoutée pour la première fois à une pile, ce qui vous permet de réagir au moment où une pile se forme.

Dans les deux cas, le `stack` champ est `null` destiné aux demandes de tirage autonomes, de sorte que les intégrations existantes qui ne s’attendent pas à ce que les piles continuent de fonctionner de façon inchangée.