Amazon n' CodeCatalyst est plus ouvert aux nouveaux clients. Les clients existants peuvent continuer à utiliser le service normalement. Pour de plus amples informations, veuillez consulter [Comment effectuer une migration depuis CodeCatalyst](migration.md).
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Révision du code à l'aide de pull requests sur Amazon CodeCatalyst
Une pull request est le principal moyen pour vous et les autres membres du projet de consulter, commenter et fusionner les modifications de code d'une branche à l'autre. Vous pouvez utiliser des pull requests pour examiner les modifications de code de manière collaborative afin de détecter des modifications ou des correctifs mineurs, des ajouts de fonctionnalités majeures ou de nouvelles versions de vos logiciels publiés. Si vous utilisez les problèmes pour suivre le travail sur votre projet, vous pouvez associer des problèmes spécifiques aux pull requests pour vous aider à suivre les problèmes résolus par les modifications de code apportées dans la pull request. Lorsque vous créez, mettez à jour, commentez, fusionnez ou fermez une pull request, un e-mail est automatiquement envoyé à l'auteur de la pull request ainsi qu'à tous les réviseurs requis ou facultatifs pour la pull request.
**Astuce**
Vous pouvez configurer les événements de pull request pour lesquels vous recevrez des e-mails dans le cadre de votre profil. Pour de plus amples informations, veuillez consulter [Envoi de notifications par Slack et par e-mail depuis CodeCatalyst](notifications-manage.md).
Les pull requests nécessitent deux branches dans un référentiel source : une branche source contenant le code que vous souhaitez réviser et une branche de destination, dans laquelle vous souhaitez fusionner le code révisé. La branche source contient l'APRÈS-validation, qui est la validation qui contient les modifications que vous souhaitez fusionner dans la branche de destination. La brande de destination contient l'AVANT-validation, qui représente l'état du code avant que la branche de la demande d'extraction ne soit fusionnée dans la branche de destination.
**Note**
Lorsque vous créez une pull request, la différence affichée est la différence entre l'extrémité de la branche source et celle de la branche de destination. Une fois que vous avez créé la pull request, la différence affichée se situe entre la révision de la pull request que vous avez choisie et le commit qui figurait au début de la branche de destination lorsque vous avez créé la pull request. Pour plus d'informations sur les différences et les bases de fusion dans Git, consultez [git-merge-base](https://git-scm.com/docs/git-merge-base)la documentation Git.
Lorsqu'une pull request est créée pour un référentiel source et des branches spécifiques, vous pouvez les créer, les afficher, les revoir et les fermer dans le cadre de votre projet. Il n'est pas nécessaire de consulter le référentiel source pour visualiser et utiliser les pull requests. L'état d'une pull request est défini sur **Ouvert** lorsque vous la créez. **La pull request reste ouverte jusqu'à ce que vous la fusionniez dans la CodeCatalyst console, ce qui change l'état en Merged, ou que vous la fermiez, ce qui change l'état en **Closed**.**
Lorsque votre code a été révisé, vous pouvez modifier l'état de la pull request de plusieurs manières :
+ Fusionnez la pull request dans la CodeCatalyst console. Le code de la branche source de la pull request sera fusionné dans la branche de destination. Le statut de la pull request deviendra **Merged**. Il ne peut pas être redéfini sur **Ouvert**.
+ Fusionnez les branches localement et appliquez vos modifications, puis fermez la pull request dans la CodeCatalyst console.
+ Utilisez la CodeCatalyst console pour fermer la pull request sans la fusionner. Cela changera le statut en **Fermé** et ne fusionnera pas le code de la branche source dans la branche de destination.
Avant de créer une demande d'extraction :
+ Validez et transférez les modifications de code que vous souhaitez vérifier dans une branche (la branche source).
+ Configurez des notifications pour votre projet afin que les autres utilisateurs puissent être informés des flux de travail exécutés lorsque vous créez une pull request. (Cette étape est facultative mais recommandée.)
**Topics**
+ [Création d’une demande pull](pull-requests-create.md)
+ [Afficher les pull requests](pull-requests-view.md)
+ [Gestion des exigences relatives à la fusion d'une pull request avec les règles d'approbation](source-pull-requests-approval-rules.md)
+ [Révision d’une demande pull](pull-requests-review.md)
+ [Mise à jour d’une demande pull](pull-requests-update.md)
+ [Fusion d’une demande pull](pull-requests-merge.md)
+ [Clôture d'une pull request](pull-requests-close.md)
# Création d’une demande pull
La création de demandes d'extraction permet aux autres utilisateurs de voir et de vérifier vos modifications de code avant de les fusionner dans une autre branche. Tout d'abord, vous devez créer une branche pour vos modifications de code. C'est ce que l'on appelle la branche source d'une demande d'extraction. Après avoir validé et transféré les modifications apportées au référentiel, vous pouvez créer une pull request qui compare le contenu de la branche source au contenu de la branche de destination.
Vous pouvez créer une pull request dans la CodeCatalyst console Amazon depuis une branche spécifique, depuis la page des pull requests ou depuis l'aperçu du projet. La création d'une pull request à partir d'une branche spécifique fournit automatiquement le nom du référentiel et la branche source sur la page de création de la pull request. Lorsque vous créez une pull request, vous recevez automatiquement des e-mails concernant toute mise à jour de la pull request, ainsi que la date de fusion ou de fermeture de la pull request.
**Note**
Lorsque vous créez une pull request, la différence affichée est la différence entre l'extrémité de la branche source et celle de la branche de destination. Une fois la pull request créée, la différence affichée se situera entre la révision de la pull request que vous avez choisie et le commit qui figurait au début de la branche de destination lorsque vous avez créé la pull request. Pour plus d'informations sur les différences et les bases de fusion dans Git, consultez [git-merge-base](https://git-scm.com/docs/git-merge-base)la documentation Git.
Vous pouvez utiliser la fonctionnalité **Rédiger une description pour moi** lorsque vous créez des pull requests pour qu'Amazon Q crée automatiquement une description des modifications contenues dans une pull request. Lorsque vous choisissez cette option, Amazon Q analyse les différences entre la branche source contenant les modifications de code et la branche de destination dans laquelle vous souhaitez fusionner ces modifications. Il crée ensuite un résumé de ces modifications, ainsi que sa meilleure interprétation de l'intention et de l'effet de ces modifications. Cette fonctionnalité n'est disponible que dans la région ouest des États-Unis (Oregon) pour les CodeCatalyst pull requests. La fonctionnalité **Écrire une description pour moi** n'est pas disponible pour les pull requests dans les référentiels liés.
**Note**
**Propulsé par Amazon Bedrock** : AWS implémente la [détection automatique des abus](https://docs.aws.amazon.com//bedrock/latest/userguide/abuse-detection.html). Étant donné que les fonctionnalités **Rédiger une description pour moi**, **Créer un résumé du contenu**, **Recommander des tâches**, **Utiliser Amazon Q pour créer ou ajouter des fonctionnalités à un projet** et **Attribuer des problèmes à Amazon Q** avec l’agent Amazon Q Developer de développement logiciel sont basées sur Amazon Bedrock, les utilisateurs peuvent tirer pleinement parti des contrôles mis en œuvre dans Amazon Bedrock pour renforcer la sûreté, la sécurité et l’utilisation responsable de l’intelligence artificielle (IA).
**Pour créer une demande d’extraction**
1. Accédez à votre projet.
1. Effectuez l’une des actions suivantes :
+ Dans le volet de navigation, choisissez **Code**, choisissez **Pull requests**, puis **Create pull request**.
+ Sur la page d'accueil du référentiel, choisissez **Plus**, puis **Create pull request**.
+ Sur la page du projet, choisissez **Create pull request**.
1. Dans le **référentiel source**, assurez-vous que le référentiel source spécifié est celui qui contient le code validé. Cette option n'apparaît que si vous n'avez pas créé la pull request depuis la page principale du dépôt.
1. Dans **Branche de destination**, choisissez la branche dans laquelle vous souhaitez fusionner le code une fois celui-ci révisé.
1. Dans **Branche source**, choisissez la branche qui contient le code validé.
1. Dans **Titre de la demande d'extraction**, entrez un titre qui aide les autres utilisateurs à comprendre ce qui doit être revu et pourquoi.
1. (Facultatif) Dans la **description de la Pull request**, fournissez des informations telles qu'un lien vers les problèmes ou une description de vos modifications.
**Astuce**
Vous pouvez choisir **Write description for me** afin de générer CodeCatalyst automatiquement une description des modifications contenues dans la pull request. Vous pouvez apporter des modifications à la description générée automatiquement après l'avoir ajoutée à la pull request.
Cette fonctionnalité nécessite que les fonctionnalités d'IA générative soient activées pour l'espace et ne sont pas disponibles pour les pull requests dans les référentiels liés. Pour plus d'informations, consultez [la section Gestion des fonctionnalités d'IA générative](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-generative-ai-features.html).
1. (Facultatif) Dans **Problèmes**, choisissez **Lier les problèmes**, puis choisissez un problème dans la liste ou entrez son ID. Pour dissocier un problème, cliquez sur l'icône de dissociation.
1. (Facultatif) Dans **Réviseurs obligatoires**, sélectionnez **Ajouter les réviseurs requis**. Choisissez parmi la liste des membres du projet pour les ajouter. Les réviseurs requis doivent approuver les modifications avant que la pull request puisse être fusionnée dans la branche de destination.
**Note**
Vous ne pouvez pas ajouter un réviseur à la fois comme réviseur obligatoire et comme réviseur facultatif. Vous ne pouvez pas vous ajouter en tant que réviseur.
1. (Facultatif) Dans **Réviseurs facultatifs**, sélectionnez **Ajouter des réviseurs facultatifs**. Choisissez parmi la liste des membres du projet pour les ajouter. Les réviseurs facultatifs n'ont pas à approuver les modifications comme condition préalable pour que la pull request puisse être fusionnée dans la branche de destination.
1. Passez en revue les différences entre les branches. La différence affichée dans une pull request réside dans les modifications entre la révision dans la branche source et la base de fusion, qui est le commit principal de la branche de destination au moment de la création de la pull request. Si aucune modification ne s'affiche, il se peut que les branches soient identiques ou que vous ayez choisi la même branche pour la source et pour la destination.
1. Lorsque vous êtes certain que la pull request contient le code et les modifications que vous souhaitez vérifier, choisissez **Create**.
**Note**
Après avoir créé la pull request, vous pouvez ajouter des commentaires. Des commentaires peuvent être ajoutés à la pull request ou à des lignes individuelles des fichiers, ainsi qu'à la pull request globale. Vous pouvez ajouter des liens vers des ressources, telles que des fichiers, en utilisant le signe @ suivi du nom du fichier.
**Pour créer une pull request depuis une branche**
1. Accédez au projet dans lequel vous souhaitez créer une pull request.
1. Dans le volet de navigation, choisissez **Référentiels sources**, puis choisissez le référentiel contenant la branche dans laquelle vous devez vérifier les modifications de code.
1. Cliquez sur la flèche déroulante à côté du nom de branche par défaut, puis sélectionnez la branche souhaitée dans la liste. Pour afficher toutes les branches d'un référentiel, choisissez **Afficher tout**.
1. Choisissez **Plus**, puis choisissez **Create pull request**.
1. Le référentiel et la branche source sont présélectionnés pour vous. Dans la **branche de destination**, choisissez la branche dans laquelle vous allez fusionner le code une fois qu'il aura été révisé. Dans le **titre de la demande Pull**, entrez un titre qui aidera les autres utilisateurs du projet à comprendre ce qui doit être révisé et pourquoi. Vous pouvez éventuellement fournir des informations supplémentaires dans la **description de la demande Pull**, par exemple en collant un lien vers des problèmes connexes ou en CodeCatalyst ajoutant une description des modifications que vous avez apportées.
**Note**
Les flux de travail configurés pour être exécutés lors d'événements de création de pull request s'exécuteront après la création de la pull request, si la branche de destination de la pull request correspond à l'une des branches spécifiées dans le flux de travail.
1. Passez en revue les différences entre les branches. Si aucune modification n'est affichée, les branches sont peut-être identiques ou vous avez peut-être choisi la même branche pour la source et pour la destination.
1. (Facultatif) Dans **Problèmes**, choisissez **Lier les problèmes**, puis choisissez un problème dans la liste ou entrez son ID. Pour dissocier un problème, cliquez sur l'icône de dissociation.
1. (Facultatif) Dans **Réviseurs obligatoires**, sélectionnez **Ajouter les réviseurs requis**. Choisissez parmi la liste des membres du projet pour les ajouter. Les réviseurs requis doivent approuver les modifications avant que la pull request puisse être fusionnée dans la branche de destination.
**Note**
Vous ne pouvez pas ajouter de réviseur à la fois comme obligatoire et facultatif. Vous ne pouvez pas vous ajouter en tant que réviseur.
1. (Facultatif) Dans **Réviseurs facultatifs**, sélectionnez **Ajouter des réviseurs facultatifs**. Choisissez parmi la liste des membres du projet pour les ajouter. Les réviseurs facultatifs n'ont pas à approuver les modifications pour que la pull request puisse être fusionnée dans la branche de destination.
1. Lorsque vous êtes certain que la pull request contient les modifications que vous souhaitez vérifier et inclut les réviseurs requis, choisissez **Create**.
Si vous avez configuré des flux de travail pour s'exécuter là où la branche correspond à la branche de destination dans la pull request, vous verrez des informations sur ces flux de travail dans la section **Vue d'ensemble**, dans la zone des **détails** de la pull request après la création de la pull request. Pour de plus amples informations, veuillez consulter [Ajouter des déclencheurs aux flux de travail](workflows-add-trigger-add.md).
# Afficher les pull requests
Vous pouvez consulter les pull requests pour un projet dans la CodeCatalyst console Amazon. La page de résumé du projet affiche toutes les pull requests ouvertes pour un projet. Pour afficher toutes les pull requests, quel que soit leur état, accédez à la page des pull requests de votre projet. Lorsque vous consultez une pull request, vous pouvez choisir de créer pour vous un résumé de tous les commentaires laissés sur les modifications apportées à la pull request.
**Note**
**Propulsé par Amazon Bedrock** : AWS implémente la [détection automatique des abus](https://docs.aws.amazon.com//bedrock/latest/userguide/abuse-detection.html). Étant donné que les fonctionnalités **Rédiger une description pour moi**, **Créer un résumé du contenu**, **Recommander des tâches**, **Utiliser Amazon Q pour créer ou ajouter des fonctionnalités à un projet** et **Attribuer des problèmes à Amazon Q** avec l’agent Amazon Q Developer de développement logiciel sont basées sur Amazon Bedrock, les utilisateurs peuvent tirer pleinement parti des contrôles mis en œuvre dans Amazon Bedrock pour renforcer la sûreté, la sécurité et l’utilisation responsable de l’intelligence artificielle (IA).
**Pour consulter les pull requests ouvertes**
1. Accédez au projet dans lequel vous souhaitez afficher les pull requests.
1. Sur la page du projet, les pull requests ouvertes sont affichées, y compris des informations sur le créateur de la pull request, le référentiel contenant les branches de la pull request et la date de création de la pull request. Vous pouvez filtrer la vue de la pull request ouverte par référentiel source.
1. Pour afficher toutes les pull requests, choisissez **Afficher tout**. Vous pouvez utiliser les sélecteurs pour choisir entre les options. Par exemple, pour afficher toutes les pull requests, choisissez **Any status** et **Any author**.
Dans le volet de navigation, vous pouvez également choisir **Code**, puis **Pull requests**, puis utiliser les sélecteurs pour affiner votre affichage.
1. Sur la **page des demandes** d'extraction, vous pouvez trier les demandes d'extraction par identifiant, titre, statut, etc. Pour personnaliser les informations et la quantité d'informations affichées sur la page des pull requests, choisissez l'icône en forme de roue dentée.
1. Pour consulter une pull request spécifique, sélectionnez-la dans la liste.
1. Pour consulter l'état des exécutions de flux de travail associées à cette pull request, le cas échéant, choisissez **Overview** et consultez les informations dans la zone des **détails de la pull request** de la pull request sous **Exécutions de flux** de travail.
Un flux de travail sera exécuté si le flux de travail est configuré avec des événements de création ou de révision de demandes d'extraction, et si les exigences de la branche de destination du flux de travail correspondent à la branche de destination spécifiée dans la demande d'extraction. Pour de plus amples informations, veuillez consulter [Ajouter des déclencheurs aux flux de travail](workflows-add-trigger-add.md).
1. Pour consulter les problèmes liés, le cas échéant, choisissez **Vue d'ensemble** et consultez les informations figurant dans les **détails de la demande d'extraction** sous **Problèmes**. Si vous souhaitez consulter un numéro lié, choisissez son ID dans la liste.
1. (Facultatif) Pour créer un résumé des commentaires laissés sur les modifications de code dans les révisions de la pull request, choisissez **Créer un résumé du contenu**. Le résumé n'inclura aucun commentaire laissé sur l'ensemble de la pull request.
**Note**
Cette fonctionnalité nécessite que les fonctionnalités d'IA générative soient activées pour l'espace, n'est pas disponible pour les référentiels liés et n'est disponible que dans la région ouest des États-Unis (Oregon). Pour plus d'informations, consultez [la section Gestion des fonctionnalités d'IA générative](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-generative-ai-features.html).
1. Pour afficher les modifications de code dans la pull request, choisissez **Changes**. Vous pouvez rapidement voir combien de fichiers ont été modifiés dans la pull request, et quels fichiers de la pull request contiennent des commentaires, dans **Fichiers modifiés**. Le nombre de commentaires affichés à côté d'un dossier indique le nombre de commentaires sur les fichiers de ce dossier. Développez le dossier pour afficher le nombre de commentaires pour chaque fichier qu'il contient. Vous pouvez également consulter les commentaires laissés sur des lignes de code spécifiques.
**Note**
Les modifications apportées à une pull request ne peuvent pas toutes être affichées dans la console. Par exemple, vous ne pouvez pas afficher les sous-modules Git dans la console. Vous ne pouvez donc pas voir les différences entre les sous-modules dans une pull request. Certaines différences sont peut-être trop importantes pour être affichées. Pour plus d’informations, consultez [Quotas pour les référentiels sources dans CodeCatalyst](source-quotas.md) et [Affichage d'un fichierAfficher l'historique des modifications apportées à un fichier](source-files-view.md).
1. Pour consulter les rapports de qualité relatifs à cette pull request, choisissez **Reports**.
**Note**
Un flux de travail doit être configuré pour générer des rapports afin qu'ils apparaissent dans vos pull requests. Pour de plus amples informations, veuillez consulter [Tests avec des flux de travailTests avec des flux de travail](test-workflow-actions.md).
# Gestion des exigences relatives à la fusion d'une pull request avec les règles d'approbation
Lorsque vous créez une pull request, vous pouvez choisir d'ajouter des réviseurs obligatoires ou facultatifs à cette demande d'extraction individuelle. Cependant, vous pouvez également créer des exigences auxquelles toutes les pull requests doivent répondre lors de la fusion vers une branche de destination spécifique. Ces exigences sont appelées règles d'approbation. Les règles d'approbation sont configurées pour les branches d'un référentiel. Lorsque vous créez une demande d'extraction pour laquelle une règle d'approbation est configurée pour la branche de destination, les exigences de cette règle doivent être satisfaites en plus des approbations de tous les réviseurs requis avant de pouvoir fusionner la demande d'extraction avec cette branche. La création de règles d'approbation peut vous aider à maintenir les normes de qualité pour les fusions avec des succursales telles que votre succursale par défaut.
Les règles d'approbation appliquées à la branche par défaut de votre référentiel source se comporteront légèrement différemment des règles d'approbation appliquées aux autres branches. Toute règle appliquée à la branche par défaut sera automatiquement appliquée à toute branche que vous spécifiez comme branche par défaut. La branche précédemment définie comme branche par défaut conservera toujours les règles qui lui sont appliquées.
Lorsque vous créez des règles d'approbation, vous devez réfléchir à la manière dont ces règles seront respectées par les utilisateurs de votre projet à la fois dans le présent et dans le futur. Par exemple, si votre projet compte six utilisateurs et que vous créez une règle d'approbation qui nécessite cinq approbations avant de pouvoir être fusionnée avec la branche de destination, vous avez effectivement créé une règle qui oblige tout le monde, sauf la personne qui a créé les pull request, à approuver cette pull request avant qu'elle ne puisse être fusionnée.
**Note**
Vous devez avoir le rôle d'administrateur de projet pour créer et gérer les règles d'approbation dans les CodeCatalyst projets. Vous ne pouvez pas créer de règles d'approbation pour les référentiels liés.
Vous ne pouvez pas supprimer les règles d'approbation, mais vous pouvez les mettre à jour pour qu'elles n'exigent aucune approbation, ce qui supprime effectivement la règle.
**Pour consulter et modifier les règles d'approbation des succursales de destination pour les pull requests**
1. Accédez au projet dans lequel se trouve votre référentiel.
1. Choisissez le nom du référentiel dans la liste des référentiels sources du projet. Dans le volet de navigation, vous pouvez également choisir **Code**, puis **Référentiels sources**.
Choisissez le référentiel dans lequel vous souhaitez consulter les règles d'approbation.
1. Sur la page d'aperçu du référentiel, choisissez **Branches**.
1. Dans la colonne **Règles d'approbation**, choisissez **Afficher** pour voir le statut de toutes les règles pour chaque branche du référentiel.
Dans **Nombre minimum d'approbations**, le nombre correspond au nombre d'approbations requises avant qu'une pull request puisse être fusionnée avec cette branche.
1. Pour créer ou modifier une règle d'approbation, choisissez **Gérer les paramètres**. Sur la page des paramètres du référentiel source, dans **Règles d'approbation**, sélectionnez **Modifier**.
**Note**
Vous devez avoir le rôle d'**administrateur de projet** pour modifier les règles d'approbation.
1. Dans **Branche**, choisissez le nom de la succursale pour laquelle vous souhaitez configurer une règle d'approbation dans la liste déroulante. Dans **Nombre minimum d'approbations**, entrez un nombre, puis choisissez **Enregistrer**.
# Révision d’une demande pull
Vous pouvez utiliser la CodeCatalyst console Amazon pour examiner et commenter de manière collaborative les modifications incluses dans une pull request. Vous pouvez ajouter des commentaires à des lignes de code individuelles en faisant la différence entre les branches source et destination, ou en fonction de la différence entre les révisions de la pull request. Vous pouvez choisir de créer un résumé des commentaires laissés sur les modifications de code dans la pull request afin de vous aider à comprendre rapidement les commentaires laissés par les autres utilisateurs. Vous pouvez également choisir de créer un environnement de développement pour travailler sur le code.
**Note**
**Propulsé par Amazon Bedrock** : AWS implémente la [détection automatique des abus](https://docs.aws.amazon.com//bedrock/latest/userguide/abuse-detection.html). Étant donné que les fonctionnalités **Rédiger une description pour moi**, **Créer un résumé du contenu**, **Recommander des tâches**, **Utiliser Amazon Q pour créer ou ajouter des fonctionnalités à un projet** et **Attribuer des problèmes à Amazon Q** avec l’agent Amazon Q Developer de développement logiciel sont basées sur Amazon Bedrock, les utilisateurs peuvent tirer pleinement parti des contrôles mis en œuvre dans Amazon Bedrock pour renforcer la sûreté, la sécurité et l’utilisation responsable de l’intelligence artificielle (IA).
**Astuce**
Vous pouvez configurer les événements de pull request pour lesquels vous recevrez des e-mails dans le cadre de votre profil. Pour de plus amples informations, veuillez consulter [Envoi de notifications par Slack et par e-mail depuis CodeCatalyst](notifications-manage.md).
Les pull requests indiquent quelle sera la différence entre la révision de la pull request et le commit qui figurait au début de la branche de destination lorsque vous avez créé la pull request. C'est ce qu'on appelle la base de fusion. Pour plus d'informations sur les différences et les bases de fusion dans Git, consultez [git-merge-base](https://git-scm.com/docs/git-merge-base)la documentation Git.
**Astuce**
Lorsque vous travaillez dans la console, en particulier si une pull request est ouverte depuis un certain temps, pensez à actualiser votre navigateur pour vous assurer que vous disposez de la dernière version disponible pour une pull request avant de commencer à la consulter.
**Pour consulter une pull request dans la CodeCatalyst console**
1. Accédez à votre projet.
1. Accédez aux pull requests en effectuant l'une des opérations suivantes :
+ Si la pull request est répertoriée sur la page du projet, choisissez-la dans la liste.
+ Si la pull request n'est pas répertoriée sur la page du projet, choisissez **Afficher tout**. Utilisez les filtres et triez pour trouver la pull request, puis choisissez-la dans la liste.
+ Dans le volet de navigation, choisissez **Code**, puis choisissez **Pull requests**.
1. Choisissez la pull request que vous souhaitez consulter dans la liste. Vous pouvez filtrer la liste des pull requests en saisissant une partie de son nom dans la barre de filtre.
1. Dans **Vue d'ensemble**, vous pouvez consulter le nom et le titre de la pull request. Vous pouvez créer et consulter les commentaires laissés sur la pull request elle-même. Vous pouvez également consulter les détails de la pull request, y compris les informations sur les exécutions du flux de travail, les problèmes liés, les réviseurs, l'auteur de la pull request et les stratégies de fusion réalisables.
**Note**
Les commentaires laissés sur des lignes de code spécifiques apparaissent dans la section **Modifications**.
1. (Facultatif) Pour ajouter un commentaire qui s'applique à l'intégralité de la pull request, développez **Commentaires sur la pull request**, puis choisissez **Create comment**.
1. (Facultatif) Pour afficher un résumé de tous les commentaires laissés concernant les modifications apportées aux révisions de cette pull request, choisissez **Créer un résumé des commentaires**.
**Note**
Cette fonctionnalité nécessite que les fonctionnalités d'IA générative soient activées pour l'espace et n'est disponible que dans la région ouest des États-Unis (Oregon). Pour plus d'informations, consultez la section [Gestion des fonctionnalités génératives de l'IA](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-generative-ai-features.html).
1. Dans **Changes**, vous pouvez voir les différences entre la branche de destination et la version la plus récente de la pull request. S'il existe plusieurs révisions, vous pouvez modifier la différence entre les révisions comparées. Pour plus d'informations sur les révisions, consultez[Révisions](source-concepts.md#revision-concept).
**Astuce**
Vous pouvez rapidement voir combien de fichiers ont été modifiés dans la pull request, et quels fichiers de la pull request contiennent des commentaires, dans **Fichiers modifiés**. Le nombre de commentaires affichés à côté d'un dossier indique le nombre de commentaires sur les fichiers de ce dossier. Développez le dossier pour afficher le nombre de commentaires pour chaque fichier qu'il contient.
1. Pour modifier la façon dont les différences sont affichées, choisissez entre **Unified** et **Split**.
1. Pour ajouter un commentaire à une ligne de la pull request, rendez-vous sur la ligne que vous souhaitez commenter. Choisissez l'icône de commentaire qui apparaît pour cette ligne, entrez un commentaire, puis cliquez **sur Enregistrer**.
1. Pour afficher les modifications entre les révisions d'une pull request, ou entre ses branches source et de destination, choisissez l'une des options disponibles dans **Comparing**. Les commentaires sur les lignes des révisions sont conservés dans ces révisions.
1. Si vous avez configuré votre flux de travail pour générer un rapport de couverture de code sur les déclencheurs de pull request, vous pouvez consulter les résultats de couverture des lignes et des succursales dans la pull request correspondante. Pour masquer les résultats relatifs à la couverture du code, choisissez **Masquer la couverture du code**. Pour de plus amples informations, veuillez consulter [Rapports de couverture du code](test-workflow-actions.md#test-code-coverage-reports).
1. Si vous souhaitez modifier le code de la pull request, vous pouvez créer un environnement de développement à partir de la pull request. Choisissez **Create Dev Environment**. Ajoutez éventuellement un nom pour l'environnement de développement ou modifiez sa configuration, puis choisissez **Create**.
1. Dans **Rapports**, vous pouvez consulter les rapports de qualité contenus dans cette pull request. S'il existe plusieurs révisions, vous pouvez modifier la différence entre les révisions comparées. Vous pouvez filtrer les rapports par nom, statut, flux de travail, action et type.
**Note**
Un flux de travail doit être configuré pour générer des rapports afin qu'ils apparaissent dans vos pull requests. Pour de plus amples informations, veuillez consulter [Configuration des rapports de qualité dans une action](test-config-action.md).
1. Pour consulter un rapport spécifique, sélectionnez-le dans la liste. Pour de plus amples informations, veuillez consulter [Tests avec des flux de travailTests avec des flux de travail](test-workflow-actions.md).
1. Si vous êtes répertorié comme réviseur de cette pull request et que vous souhaitez approuver les modifications, assurez-vous de consulter la révision la plus récente, puis choisissez **Approuver**.
**Note**
Tous les réviseurs requis doivent approuver une pull request avant de pouvoir la fusionner.
# Mise à jour d’une demande pull
Vous pouvez faciliter la révision du code par les autres membres du projet en mettant à jour la pull request. Vous pouvez mettre à jour une pull request pour modifier ses réviseurs, ses liens vers des problèmes, le titre de la pull request ou sa description. Par exemple, vous souhaiterez peut-être modifier les réviseurs requis pour une pull request afin de supprimer une personne en vacances et d'ajouter quelqu'un d'autre. Vous pouvez également mettre à jour une pull request avec d'autres modifications de code en envoyant des validations vers la branche source d'une pull request ouverte. Chaque envoi vers la branche source d'une pull request dans le référentiel CodeCatalyst source crée une révision. Les membres du projet peuvent voir les différences entre les révisions dans une pull request.
**Pour mettre à jour les réviseurs d'une pull request**
1. Accédez au projet dans lequel vous souhaitez mettre à jour les réviseurs d'une pull request.
1. Sur la page du projet, sous **Ouvrir les pull requests**, choisissez la pull request dans laquelle vous souhaitez mettre à jour les réviseurs. Sinon, dans le volet de navigation, choisissez **Code**, choisissez **Pull requests**, puis choisissez la pull request que vous souhaitez mettre à jour.
1. (Facultatif) Dans **Vue d'ensemble**, dans la **zone des détails de la demande** d'extraction, choisissez le signe plus pour ajouter des réviseurs obligatoires ou facultatifs. Cliquez sur le **X** à côté d'un réviseur pour le supprimer en tant que réviseur facultatif ou obligatoire.
1. (Facultatif) Dans **Vue d'ensemble**, **dans la zone Détails de la demande** d'extraction, choisissez Lier les **problèmes** pour lier un problème à la demande d'extraction, puis choisissez un problème dans la liste ou entrez son ID. Pour dissocier un problème, cliquez sur l'icône de dissociation à côté du problème que vous souhaitez dissocier.
**Pour mettre à jour les fichiers et le code dans la branche source d'une pull request**
1. Pour mettre à jour plusieurs fichiers, [créez un environnement](devenvironment-create.md) de développement ou clonez le référentiel et sa branche source et utilisez un client Git ou un environnement de développement intégré (IDE) pour apporter des modifications aux fichiers de la branche source. Validez et envoyez les modifications à la branche source dans le référentiel CodeCatalyst source pour mettre automatiquement à jour la pull request avec les modifications. Pour plus d’informations, consultez [Clonage d’un référentiel source](source-repositories-clone.md) et [Comprendre les modifications apportées au code source à l'aide de validations sur Amazon CodeCatalyst](source-commits.md).
1. Pour mettre à jour un fichier individuel dans une branche source, vous pouvez utiliser un client Git ou un IDE comme vous le feriez pour plusieurs fichiers. Vous pouvez également le modifier directement dans la CodeCatalyst console. Pour de plus amples informations, veuillez consulter [Modification d'un fichier](source-files-edit.md).
**Pour mettre à jour le titre et la description d'une pull request**
1. Accédez au projet dans lequel vous souhaitez mettre à jour le titre ou la description d'une pull request.
1. La page du projet affiche les pull requests ouvertes, y compris des informations sur le créateur de la pull request, le référentiel contenant les branches de la pull request et la date de création de la pull request. Vous pouvez filtrer la vue de la pull request ouverte par référentiel source. Choisissez la pull request que vous souhaitez modifier dans la liste.
1. Pour afficher toutes les pull requests, choisissez **Afficher tout**. Dans le volet de navigation, vous pouvez également choisir **Code**, puis **Pull requests**. Utilisez la boîte de filtre ou les fonctions de tri pour trouver la pull request que vous souhaitez modifier, puis choisissez-la.
1. Dans **Vue d'ensemble**, choisissez **Modifier**.
1. Modifiez le titre ou la description, puis choisissez **Enregistrer**.
# Fusion d’une demande pull
Une fois que votre code a été révisé et que tous les réviseurs requis l'ont approuvé, vous pouvez fusionner une pull request dans la CodeCatalyst console en utilisant une stratégie de fusion compatible, telle que fast-forward. Toutes les stratégies de fusion prises en charge dans la CodeCatalyst console ne sont pas disponibles en tant que choix pour toutes les pull requests. CodeCatalyst évalue la fusion et vous permet uniquement de choisir entre les stratégies de fusion disponibles dans la console et capables de fusionner la branche source avec la branche de destination. Vous pouvez également fusionner une pull request avec les stratégies de fusion Git de votre choix en exécutant la **git merge** commande sur votre ordinateur local ou dans un environnement de développement pour fusionner la branche source dans la branche de destination. Vous pouvez ensuite transférer ces modifications de la branche de destination vers le référentiel source CodeCatalyst.
**Note**
La fusion de la branche et l'application des modifications dans Git ne ferme pas automatiquement la pull request.
Si vous avez le rôle d'administrateur de projet, vous pouvez également choisir de fusionner une pull request qui ne répond pas encore à toutes les exigences en matière d'approbations et de règles d'approbation.
## Fusion d'une pull request (console)
Vous pouvez fusionner une pull request dans la CodeCatalyst console s'il n'y a aucun conflit de fusion entre les branches source et destination et si tous les réviseurs requis ont approuvé la pull request. En cas de conflit ou si la fusion ne peut pas être terminée, le bouton de fusion est inactif et une étiquette **Non fusionnable** s'affiche. Dans ce cas, vous devez obtenir l'approbation de tous les approbateurs requis, résoudre les conflits localement si nécessaire et appliquer ces modifications avant de pouvoir fusionner. La fusion d'une pull request enverra automatiquement un e-mail au créateur de la pull request ainsi qu'à tous les réviseurs obligatoires ou facultatifs. Il ne fermera ni ne modifiera automatiquement le statut des problèmes liés à la pull request.
**Astuce**
Vous pouvez configurer les événements de pull request pour lesquels vous recevrez des e-mails dans le cadre de votre profil. Pour de plus amples informations, veuillez consulter [Envoi de notifications par Slack et par e-mail depuis CodeCatalyst](notifications-manage.md).
**Pour fusionner une pull request**
1. Accédez au projet dans lequel vous souhaitez fusionner une pull request.
1. Sur la page du projet, sous **Ouvrir les pull requests**, choisissez la pull request que vous souhaitez fusionner. Si vous ne voyez pas la pull request, choisissez **Afficher toutes les pull requests**, puis choisissez-la dans la liste. Sinon, dans le volet de navigation, choisissez **Code**, choisissez **Pull requests**, puis choisissez la pull request que vous souhaitez fusionner. Choisissez **Merge (Fusionner)**.
1. Choisissez parmi les stratégies de fusion disponibles pour la pull request. **Vous pouvez éventuellement sélectionner ou désélectionner l'option permettant de supprimer la branche source après avoir fusionné la pull request, puis choisissez Merge.**
**Note**
Si le bouton **Fusionner** est inactif ou si le libellé **Non fusionnable** s'affiche, cela signifie que les réviseurs requis n'ont pas encore approuvé la pull request ou que la pull request ne peut pas être fusionnée dans la CodeCatalyst console. Un réviseur qui n'a pas approuvé une pull request est indiqué par une icône en forme d'horloge dans la zone des **détails de la pull request** dans **Vue d'ensemble**. Si tous les réviseurs requis ont approuvé la pull request mais que le bouton **Fusionner** est toujours inactif, il se peut que vous ayez un conflit de fusion. Choisissez le libellé **Non fusionnable** souligné pour obtenir plus de détails sur les raisons pour lesquelles la pull request ne peut pas être fusionnée. Vous pouvez résoudre les conflits de fusion pour la branche de destination dans un environnement de développement ou dans la CodeCatalyst console, puis fusionner la pull request, ou vous pouvez résoudre les conflits et fusionner localement, puis transférer le commit contenant la fusion vers la branche source in CodeCatalyst. Pour plus d'informations, consultez [Fusion d'une pull request (Git)](#pull-requests-merge-git) votre documentation Git.
## Ignorer les exigences relatives à la fusion
Si vous avez le rôle d'**administrateur de projet**, vous pouvez choisir de fusionner une pull request qui ne répond pas encore à toutes les exigences en matière d'approbations et de règles d'approbation requises. C'est ce que l'on appelle le remplacement des exigences d'une pull request. Vous pouvez choisir de le faire si le réviseur requis n'est pas disponible ou s'il est urgent de fusionner une pull request spécifique dans une branche dont les règles d'approbation ne peuvent pas être respectées rapidement.
**Pour fusionner une pull request**
1. Dans la pull request dans laquelle vous souhaitez annuler les exigences et fusionner, cliquez sur la flèche déroulante à côté du bouton **Fusionner**. Choisissez **Ignorer les exigences d'approbation.**
1. Dans **Raison de dérogation**, expliquez pourquoi vous fusionnez cette pull request sans qu'elle réponde aux règles d'approbation et aux exigences requises en matière de révision. Bien que cela soit facultatif, cela est fortement recommandé.
1. Choisissez éventuellement une stratégie de fusion ou acceptez la stratégie par défaut. Vous pouvez également choisir de mettre à jour le message de validation généré automatiquement avec plus de détails.
1. Sélectionnez ou désélectionnez l'option permettant de supprimer la branche source lors de la fusion. Nous vous recommandons de conserver la branche source lorsque vous passez outre aux exigences relatives à la fusion d'une pull request jusqu'à ce que vous ayez eu l'occasion de revoir la décision avec les autres membres de l'équipe.
1. Choisissez **Merge (Fusionner)**.
## Fusion d'une pull request (Git)
Git propose de nombreuses options de fusion et de gestion de branches. Les commandes suivantes sont quelques-unes des options que vous pouvez utiliser. Pour plus d'informations, consultez la documentation disponible sur le [site Web de Git](https://git-scm.com/doc). Une fois que vous avez fusionné et appliqué vos modifications, fermez manuellement la pull request. Pour de plus amples informations, veuillez consulter [Clôture d'une pull request](pull-requests-close.md).
**Commandes Git communes pour la fusion de branches**
| | |
| --- |--- |
| Fusionne les modifications de la branche source du dépôt local vers la branche de destination du dépôt local. | `git checkout destination-branch-name` `git merge source-branch-name` |
| Fusionne la branche source dans la branche de destination, en spécifiant une fusion rapide. Cela fusionne les branches et déplace le pointeur de branche de destination vers l'extrémité de la branche source. | `git checkout destination-branch-name` `git merge --ff-only source-branch-name` |
| Fusionne la branche source avec la branche de destination, en spécifiant une fusion par squash. Cela combine tous les commits de la branche source en un seul commit de fusion dans la branche de destination. | `git checkout destination-branch-name` `git merge --squash source-branch-name` |
| Fusionne la branche source dans la branche de destination, en spécifiant une fusion à trois voies. Cela crée un commit de fusion et ajoute les validations individuelles de la branche source à la branche de destination. | `git checkout destination-branch-name` `git merge --no-ff source-branch-name` |
| Supprime la branche source dans le dépôt local. Cela est utile pour nettoyer votre dépôt local après avoir fusionné avec la branche de destination et transféré les modifications au référentiel source. | `git branch -d source-branch-name` |
| Supprime la branche source du référentiel distant (le référentiel source dans CodeCatalyst) en utilisant le surnom spécifié par le dépôt local pour le référentiel distant. (Notez l'utilisation du signe deux points (`:`).) Vous pouvez également `--delete` le spécifier dans le cadre de la commande. | `git push remote-name :source-branch-name` `git push remote-name --delete source-branch-name` |
# Clôture d'une pull request
Vous pouvez marquer une pull request comme étant **fermée**. Cela ne fusionne pas les pull requests, mais cela peut vous aider à déterminer quelles sont les pull requests qui nécessitent une action et celles qui ne sont plus pertinentes. Nous vous recommandons de fermer une pull request si vous ne prévoyez plus de fusionner ces modifications ou si les modifications ont été fusionnées par une autre pull request.
La fermeture d'une pull request enverra automatiquement un e-mail au créateur de la pull request ainsi qu'à tous les réviseurs obligatoires ou facultatifs. Cela ne modifiera pas automatiquement le statut des problèmes liés à la pull request.
**Note**
Vous ne pouvez pas rouvrir une pull request une fois qu'elle a été fermée.
**Pour fermer une pull request**
1. Accédez au projet dans lequel vous souhaitez fermer une pull request.
1. Sur la page du projet, les pull requests ouvertes sont affichées. Choisissez la pull request que vous souhaitez fermer.
1. Choisissez **Fermer**.
1. Passez en revue les informations, puis choisissez **Fermer la pull request**.