# Résolution des problèmes liés aux pull requests empilées Résolvez les problèmes courants liés aux pull requests empilées, notamment les conflits de rebasage, les fusions bloquées, les opérations interrompues et les problèmes de file d’attente de fusion. > \[!NOTE] Cette fonctionnalité est disponible en préversion publique et peut être modifiée. Cet article aborde les problèmes courants que vous pouvez rencontrer lorsque vous travaillez avec des pull requests en pile et explique comment les résoudre. ## Une rebase signale un conflit Lorsqu’une rebase en cascade rencontre un conflit, `gh stack rebase` arrête et répertorie les fichiers en conflit. Pour résoudre le conflit et continuer : 1. Ouvrez chaque fichier en conflit et résolvez les marqueurs de conflit (`<<<<<<<`, `=======`, `>>>>>>>`). 2. Étape des fichiers résolus. ```shell git add . ``` 3. Poursuivez le rebasage. Les branches restantes sont rebasées automatiquement. ```shell gh stack rebase --continue ``` Si le conflit est trop complexe ou que vous souhaitez recommencer, abandonnez le rebasage pour restaurer toutes les branches dans l’état où elles se trouvaient avant le rebasage. ```shell gh stack rebase --abort ``` ## Une synchronisation s’est arrêtée en raison d’un conflit Si un conflit est détecté lors de l’exécution `gh stack sync`, toutes les branches sont restaurées à leur état d’origine afin que rien ne soit partiellement mis à jour. Résolvez le conflit de manière interactive en exécutant une nouvelle base directement, puis envoyez (push) les branches mises à jour. ```shell gh stack rebase gh stack push ``` ## Une session de modification ne démarre pas `gh stack modify` nécessite un état de démarrage propre. S’il ne démarre pas, vérifiez que : * Vous avez une stack active extraite. * Votre arbre de travail est propre. * Aucun rebasage n’est en cours. * Aucune pull request n’est en attente de fusion. * L’historique des commits est linéaire. Si ce n’est pas le cas, exécutez `gh stack rebase` d’abord. ## Une session de modification a été interrompue Si `gh stack modify` est interrompu, par exemple en raison d’un conflit que vous ne souhaitez pas résoudre ou d’un plantage du terminal, vous pouvez restaurer la pile à l’état dans lequel elle se trouvait avant de commencer. Un instantané de pré-modification est mis en cache localement pour la récupération. ```shell gh stack modify --abort ``` En cas de conflit lors de l’application des modifications et si vous souhaitez reprendre l’opération, résolvez le conflit, indexez les fichiers avec `git add`, puis exécutez `gh stack modify --continue`. ## Une pull request ne peut pas être fusionnée Une demande de tirage dans une pile ne peut fusionner que lorsqu’elle, et chaque demande de tirage en dessous, répond à toutes les exigences de fusion et la pile a un historique entièrement linéaire. Si la fusion est bloquée, vérifiez que : * La pull request et toutes les pull requests en dessous ont reçu les validations requises et des vérifications réussies. * La pile a un historique linéaire. Si les modifications ont été poussées vers une branche inférieure ou le tronc déplacé vers l’avant, l’historique peut ne plus être linéaire. Pour restaurer un historique linéaire, exécutez `gh stack rebase` , puis `gh stack push`, ou cliquez sur **Rebase stack** dans la zone de fusion. Pour les instructions, consultez [Gestion des demandes de tirage empilées](/fr/pull-requests/how-tos/create-pull-requests/managing-stacked-pull-requests). ## La fusion s’est arrêtée à travers la pile Les vérifications de pré-fusion s’exécutent avant toute fusion, mais une fusion peut toujours échouer. Par exemple, en raison d’un conflit inattendu ou d’une défaillance intermittente. Si un échec se produit en cours de route, la fusion s’arrête sur cette pull request. * Les pull requests en dessous de celle-ci qui ont été fusionnées avec succès restent intégrées à la branche de base. * La pull request qui a échoué et les pull requests situées au-dessus restent ouvertes. Résolvez le problème dans la pull request en échec, puis réessayez la fusion pour intégrer le reste de la pile. ## Une pull request a été supprimée de la file de fusion Les piles restent regroupées dans la file d’attente de fusion. 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 éjectées et supprimées. Ajoutez de nouveau la stack dans la file d’attente une fois le problème sous-jacent résolu. Une pile importante peut également s’étendre sur plusieurs groupes de fusion consécutifs : la file d’attente de fusion permet à un groupe de fusion de dépasser sa taille maximale configurée de jusqu’à 50 % afin de garder la pile intacte, et les pull requests qui n’y tiennent pas sont reportées dans les groupes suivants jusqu’à ce que toute la pile ait été fusionnée. ## Vous avez fermé une pull request en plein milieu de la pile Fermer une pull request au milieu d’une pile empêche toutes les pull requests au-dessus d’elle d’être fusionnées. La relation d’empilement est conservée, donc pour ouvrir une autre pull request ou modifier la structure de la pile, vous devez d’abord dissoudre la pile, puis la recréer. Vous pouvez décompresser à partir du GitHub site web, ou restructurer la pile avec `gh stack modify`. Retirer de la pile supprime uniquement les pull requests ouvertes, à l’état de brouillon et fermées ; les pull requests fusionnées et en file d’attente restent dans la pile. Consultez [Gestion des demandes de tirage empilées](/fr/pull-requests/how-tos/create-pull-requests/managing-stacked-pull-requests#unstacking-from-the-github-website) et [Gestion des demandes de tirage empilées](/fr/pull-requests/how-tos/create-pull-requests/managing-stacked-pull-requests#restructuring-a-stack). ## Vous ne pouvez pas créer une stack entre plusieurs forks 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.