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. # Stockez du code et collaborez sur celui-ci avec des référentiels de sources dans CodeCatalyst CodeCatalyst les référentiels sources sont des référentiels Git hébergés sur Amazon. CodeCatalyst Vous pouvez utiliser des référentiels sources CodeCatalyst pour stocker, versionner et gérer en toute sécurité les actifs d'un projet. Les actifs d'un CodeCatalyst référentiel peuvent inclure : + documents + code source + fichiers binaires CodeCatalyst utilise également le référentiel source d'un projet pour stocker les informations de configuration de votre projet, telles que les fichiers de configuration du flux de travail. Vous pouvez avoir plusieurs référentiels sources dans un CodeCatalyst projet. Par exemple, vous souhaiterez peut-être disposer de référentiels sources distincts pour le code source frontal, le code source principal, les utilitaires et la documentation. Voici un flux de travail possible pour travailler avec du code dans les référentiels sources, les pull requests et les environnements de développement dans CodeCatalyst : Mary Major crée un projet d'application Web à CodeCatalyst l'aide d'un plan, qui crée un référentiel source contenant un exemple de code. Elle invite ses amis Li Juan, Saanvi Sarkar et Jorge Souza à travailler sur le projet avec elle. Li Juan examine l'exemple de code dans le référentiel source et décide d'apporter quelques modifications rapides pour ajouter un test au code. Li crée un environnement de développement, le choisit AWS Cloud9 comme IDE et spécifie une nouvelle branche,*test-code*. L'environnement de développement s'ouvre. Li ajoute rapidement le code, puis valide et introduit la branche contenant les modifications apportées au CodeCatalyst référentiel source. Li crée ensuite une pull request. Dans le cadre de la création de cette pull request, Li ajoute Jorge Souza et Saanvi Sarkar en tant que réviseurs pour s'assurer que le code est révisé. Lors de la révision du code, Jorge Souza se souvient qu'il possède son propre référentiel de projets GitHub contenant un prototype de l'application sur laquelle ils travaillent. Il demande à Mary Major d'installer et de configurer l'extension qui lui permettra de lier le GitHub dépôt au projet en tant que dépôt source supplémentaire. Mary passe en revue le référentiel GitHub et travaille avec Jorge pour configurer l' GitHub extension afin qu'il puisse lier le GitHub référentiel en tant que référentiel source supplémentaire pour le projet. CodeCatalyst les référentiels sources prennent en charge les fonctionnalités standard de Git et fonctionnent avec vos outils Git existants. Vous pouvez créer et utiliser des jetons d'accès personnels (PATs) comme mot de passe spécifique à une application lors du clonage et de l'utilisation de référentiels sources à partir d'un client Git ou d'environnements de développement intégrés (). IDEs Ils PATs sont associés à votre identité CodeCatalyst d'utilisateur. Pour de plus amples informations, veuillez consulter [Accorder aux utilisateurs l'accès au référentiel avec des jetons d'accès personnels](ipa-tokens-keys.md). CodeCatalyst les référentiels sources prennent en charge les pull requests. Il s'agit d'un moyen simple pour vous et les autres membres du projet d'examiner et de commenter les modifications de code avant de les fusionner d'une branche à l'autre. Vous pouvez consulter les modifications dans la CodeCatalyst console et commenter les lignes de code. Les push vers les branches d'un référentiel CodeCatalyst source peuvent démarrer automatiquement une exécution dans un flux de travail, où les modifications peuvent être créées, testées et déployées. Si votre référentiel source a été créé dans le cadre d'un projet à l'aide d'un modèle de projet, un ou plusieurs flux de travail sont configurés pour vous dans le cadre du projet. Vous pouvez ajouter des flux de travail supplémentaires pour les référentiels à tout moment. Les fichiers de configuration YAML pour les flux de travail d'un projet sont stockés dans les référentiels sources configurés dans l'action source pour ces flux de travail. Pour de plus amples informations, veuillez consulter [Commencer à utiliser les flux de travail](workflows-getting-started.md). **Topics** + [Concepts du référentiel source](source-concepts.md) + [Configuration pour travailler avec les référentiels sources](source-setting-up.md) + [Commencer à utiliser les référentiels de CodeCatalyst sources et le plan d'application d'une seule page](source-getting-started.md) + [Stockage du code source dans des référentiels pour un projet dans CodeCatalyst](source-repositories.md) + [Organisation de votre code source : travaillez avec des branches sur Amazon CodeCatalyst](source-branches.md) + [Gestion des fichiers de code source sur Amazon CodeCatalyst](source-files.md) + [Révision du code à l'aide de pull requests sur Amazon CodeCatalyst](source-pull-requests.md) + [Comprendre les modifications apportées au code source à l'aide de validations sur Amazon CodeCatalyst](source-commits.md) + [Quotas pour les référentiels sources dans CodeCatalyst](source-quotas.md) # Concepts du référentiel source Voici quelques concepts à connaître lorsque vous travaillez avec des référentiels CodeCatalyst sources. **Topics** + [Projets](#project-concept) + [Référentiels sources](#source-repository-concept) + [Environnements de développement](#devenvironment-concept) + [Jetons d'accès personnels (PATs)](#personal-access-token-concept) + [Branches](#branches-concept) + [Branches par défaut](#default-branch-concept) + [Validations](#commits-concept) + [Demandes pull](#pull-request-concept) + [Révisions](#revision-concept) + [Flux de travail](#workflow-concept) ## Projets Un *projet* représente un effort de collaboration CodeCatalyst qui soutient les équipes et les tâches de développement. Une fois que vous avez un projet, vous pouvez ajouter, mettre à jour ou supprimer des utilisateurs et des ressources, personnaliser le tableau de bord de votre projet et suivre l'avancement du travail de votre équipe. Vous pouvez avoir plusieurs projets au sein d'un même espace. Les référentiels sources sont spécifiques aux projets dans lesquels vous les créez ou les liez dans un espace. Vous ne pouvez pas partager un référentiel entre projets et vous ne pouvez pas lier un référentiel à plusieurs projets dans un espace. Les utilisateurs ayant le rôle de **contributeur** ou d'**administrateur** de projet dans un projet peuvent interagir avec les référentiels sources associés à ce projet conformément aux autorisations accordées à ces rôles. Pour de plus amples informations, veuillez consulter [Octroi d'accès avec des rôles d'utilisateur](ipa-roles.md). ## Référentiels sources Un *référentiel source* est l'endroit où vous stockez en toute sécurité le code et les fichiers de votre projet. Il enregistre également l'historique des versions de vos fichiers. Par défaut, un référentiel source est partagé avec les autres utilisateurs de votre CodeCatalyst projet. Vous pouvez disposer de plusieurs référentiels sources pour un projet. Vous pouvez créer des référentiels sources pour les projets dans CodeCatalyst, ou vous pouvez choisir de lier un référentiel source existant hébergé par un autre service si ce service est pris en charge par une extension installée. Par exemple, vous pouvez lier un GitHub dépôt à un projet après avoir installé l'extension **GitHub Repositories**. Pour plus d’informations, consultez [Stockage du code source dans des référentiels pour un projet dans CodeCatalyst](source-repositories.md) et [Démarrage rapide : installation d'extensions, connexion de fournisseurs et liaison de ressources dans CodeCatalyst](extensions-quickstart.md). ## Environnements de développement Un *environnement* de développement est un environnement de développement basé sur le cloud que vous pouvez utiliser CodeCatalyst pour travailler rapidement sur le code stocké dans les référentiels sources de votre projet. Les outils de projet et les bibliothèques d'applications inclus dans votre environnement de développement sont définis par un fichier de développement dans le référentiel source de votre projet. Si vous n'avez pas de fichier de développement dans votre dépôt source, un fichier de développement par défaut sera automatiquement appliqué. Le fichier de développement par défaut inclut des outils pour les langages de programmation et les frameworks les plus fréquemment utilisés. Par défaut, un environnement de développement est configuré pour disposer d'un processeur à 2 cœurs, de 4 Go de RAM et de 16 Go de stockage persistant. Vous pouvez choisir de cloner une branche existante de votre référentiel source dans votre environnement de développement, ou vous pouvez choisir de créer une nouvelle branche dans le cadre de la création de l'environnement de développement. ## Jetons d'accès personnels (PATs) Un *jeton d'accès personnel* (PAT) est similaire à un mot de passe. Il est associé à votre identité d'utilisateur pour être utilisé dans tous les espaces et projets de CodeCatalyst. Vous pouvez accéder PATs à CodeCatalyst des ressources qui incluent des environnements de développement intégrés (IDEs) et des référentiels de sources basés sur Git. PATs vous représentent CodeCatalyst et vous pouvez les gérer dans vos paramètres utilisateur. Un utilisateur peut avoir plusieurs PAT. Les jetons d'accès personnels ne s'affichent qu'une seule fois. Il est recommandé de les stocker en toute sécurité sur votre ordinateur local. Par défaut, PATs expirent au bout d'un an. Lorsque vous travaillez avec des environnements de développement intégrés (IDEs), PATs ils sont l'équivalent d'un mot de passe Git. Fournissez le PAT lorsqu'on vous demande un mot de passe lors de la configuration de votre IDE pour qu'il fonctionne avec un dépôt Git. Pour plus d'informations sur la façon de connecter votre IDE à un référentiel basé sur Git, consultez la documentation de votre IDE. ## Branches Une *branche* est un pointeur ou une référence vers un commit dans Git et dans CodeCatalyst. Vous pouvez utiliser des branches pour organiser votre travail. Par exemple, vous pouvez utiliser des branches pour travailler sur une version nouvelle ou différente de fichiers sans affecter les fichiers des autres branches. Vous pouvez utiliser des branches pour développer de nouvelles fonctionnalités, stocker une version spécifique de votre projet, etc. Un dépôt source peut comporter une ou plusieurs branches. Lorsque vous créez un projet à l'aide d'un modèle, le référentiel source créé pour le projet contient des exemples de fichiers dans une branche appelée **main**. La branche **principale** est la branche par défaut du référentiel. ## Branches par défaut Les référentiels source CodeCatalyst ont une branche par défaut, quelle que soit la manière dont vous les créez. Si vous choisissez de créer un projet à l'aide d'un modèle, le référentiel source créé pour ce projet inclut un fichier README.md en plus des exemples de code, des définitions de flux de travail et d'autres ressources. Si vous créez un référentiel source sans utiliser de modèle, un fichier README.md est ajouté pour vous lors de la première validation et une branche par défaut est créée pour vous dans le cadre de la création du référentiel. Cette branche par défaut est nommée *main*. Cette branche par défaut est celle utilisée comme branche de base ou par défaut dans les référentiels locaux (dépôts) lorsque les utilisateurs clonent le référentiel. Vous pouvez modifier la branche utilisée comme branche par défaut. Pour de plus amples informations, veuillez consulter [Gestion de la branche par défaut d'un dépôt](source-branches-default-branch.md). Vous ne pouvez pas supprimer la branche par défaut d'un dépôt source. Les résultats de recherche incluent uniquement les résultats de la branche par défaut. ## Validations Un *commit* est une modification apportée à un fichier ou à un ensemble de fichiers. Dans la CodeCatalyst console Amazon, un commit enregistre vos modifications et les envoie vers un référentiel source. Le commit inclut des informations sur le changement, notamment l'identité de l'utilisateur qui a effectué le changement, l'heure et la date du changement, le titre du commit et tout message inclus concernant le changement. Pour de plus amples informations, veuillez consulter [Comprendre les modifications apportées au code source à l'aide de validations sur Amazon CodeCatalyst](source-commits.md). Dans le contexte d'un dépôt source en CodeCatalyst, les validations sont des instantanés du contenu et des modifications apportées au contenu de votre dépôt. Vous pouvez également ajouter des balises Git aux validations, afin d'identifier des validations spécifiques. ## Demandes pull Une *pull request* est le principal moyen par lequel vous et les autres utilisateurs examinez, commentez et fusionnez les modifications de code d'une branche à l'autre dans un référentiel source. 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. Dans une pull request, vous pouvez examiner les modifications entre les branches source et de destination ou les différences entre les révisions de ces branches. Vous pouvez ajouter des commentaires à des lignes de code individuelles ainsi que des commentaires sur la pull request dans son ensemble. **Astuce** 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. ## Révisions Une *révision* est une version mise à jour d'une pull request. Chaque envoi vers la branche source d'une pull request crée une révision qui contient les modifications apportées aux validations incluses dans ce push. Vous pouvez voir les différences entre les révisions d'une pull request en plus des différences entre les branches source et de destination. Pour de plus amples informations, veuillez consulter [Révision du code à l'aide de pull requests sur Amazon CodeCatalyst](source-pull-requests.md). ## Flux de travail Un *flux de travail* est une procédure automatisée qui décrit comment créer, tester et déployer votre code dans le cadre d'un système d'intégration et de livraison continues (CI/CD). Un flux de travail définit une série d'étapes, ou d'*actions*, à effectuer lors de son exécution. Un flux de travail définit également les événements, ou *déclencheurs*, qui déclenchent le démarrage du flux de travail. Pour configurer un flux de travail, vous devez créer un *fichier de définition de flux* de travail à l'aide de l'[éditeur visuel ou YAML](https://docs.aws.amazon.com//codecatalyst/latest/userguide/flows.html#workflow.editors) de la CodeCatalyst console. **Astuce** Pour un aperçu rapide de la manière dont vous pouvez utiliser les flux de travail dans un projet, [créez un projet avec un plan](https://docs.aws.amazon.com//codecatalyst/latest/userguide/projects-create.html#projects-create-console-template). Chaque plan déploie un flux de travail fonctionnel que vous pouvez examiner, exécuter et tester. Un référentiel source peut également stocker les fichiers de configuration et d'autres informations relatives aux flux de travail, aux notifications, aux problèmes et aux autres informations de configuration du projet. Les fichiers de configuration sont créés et stockés dans le référentiel source lorsque vous créez des ressources qui nécessitent des fichiers de configuration ou lorsque vous spécifiez le référentiel comme action source pour un flux de travail. Si vous créez un projet à partir d'un plan, les fichiers de configuration seront déjà stockés dans le référentiel source créé pour vous dans le cadre du projet. Ces informations de configuration sont stockées dans un dossier nommé `.codecatalyst` dans la branche par défaut de votre référentiel. Chaque fois que vous créez une branche de la branche par défaut, vous créez une copie de ce dossier et de sa configuration en plus de tous les autres fichiers et dossiers de cette branche. # Configuration pour travailler avec les référentiels sources Lorsque vous travaillez avec des référentiels de sources dans Amazon CodeCatalyst sur votre machine locale, vous pouvez utiliser Git seul ou dans un environnement de développement intégré (IDE) pris en charge pour apporter des modifications au code et envoyer et extraire votre code. En tant que bonne pratique, nous vous recommandons d'utiliser les dernières versions de Git et des autres logiciels. **Note** Si vous utilisez des environnements de développement, il n'est pas nécessaire d'installer Git. Une version récente de Git est incluse dans votre environnement de développement. **Informations de compatibilité des versions pour CodeCatalyst** | Composant | Version | | --- | --- | | Git | dernières | ## Installez Git Pour travailler avec des fichiers, des validations, des branches et d'autres informations dans des référentiels sources à partir d'un client Git sans IDE, installez Git sur votre machine locale. Pour installer Git, nous recommandons des sites Web tels que [Git Downloads](http://git-scm.com/downloads). ## Créez un jeton d'accès personnel Pour cloner des référentiels sources sur votre machine locale ou sur votre IDE préféré, vous devez créer un jeton d'accès personnel (PAT). **Pour créer un jeton d'accès personnel (PAT)** 1. Dans la barre de menu supérieure, choisissez votre badge de profil, puis sélectionnez **Mes paramètres**. **Astuce** Vous pouvez également accéder à votre profil utilisateur en vous rendant sur la page des membres d'un projet ou d'un espace et en choisissant votre nom dans la liste des membres. 1. Dans **Nom du PAT**, entrez un nom descriptif pour votre PAT. 1. Dans **Date d'expiration**, laissez la date par défaut ou cliquez sur l'icône du calendrier pour sélectionner une date personnalisée. La date d'expiration par défaut est d'un an à compter de la date actuelle. 1. Choisissez **Créer**. Vous pouvez également créer ce jeton lorsque vous choisissez **Clone un référentiel** pour un référentiel source. 1. Enregistrez le secret PAT dans un emplacement sécurisé. **Important** Le secret PAT ne s'affiche qu'une seule fois. Vous ne pouvez pas le récupérer après avoir fermé la fenêtre. # Commencer à utiliser les référentiels de CodeCatalyst sources et le plan d'application d'une seule page Suivez les étapes de ce didacticiel pour apprendre à utiliser les référentiels de sources sur Amazon CodeCatalyst. Le moyen le plus rapide de commencer à travailler avec les référentiels de sources sur Amazon CodeCatalyst est de créer un projet à l'aide d'un modèle. Lorsque vous créez un projet à l'aide d'un modèle, des ressources sont créées pour vous, notamment un référentiel de sources contenant un exemple de code. Vous pouvez utiliser ce référentiel et cet exemple de code pour apprendre à : + Afficher les référentiels sources d'un projet et parcourir leur contenu + Créez un environnement de développement avec une nouvelle branche dans laquelle vous pouvez travailler sur le code + Modifiez un fichier, validez et publiez vos modifications + Créez une pull request et passez en revue les modifications apportées au code avec les autres membres du projet + Consultez le flux de travail de votre projet : créez et testez automatiquement les modifications dans la branche source de la pull request. + Fusionnez vos modifications de votre branche source dans la branche de destination et fermez la pull request + Découvrez les modifications fusionnées créées et déployées automatiquement Pour tirer le meilleur parti de ce didacticiel, invitez d'autres personnes à rejoindre votre projet afin de pouvoir travailler ensemble sur une pull request. Vous pouvez également explorer des fonctionnalités supplémentaires dans CodeCatalyst, telles que la création de problèmes et leur association à une pull request, ou la configuration de notifications et la réception d'alertes lorsque le flux de travail associé s'exécute. Pour une exploration complète de CodeCatalyst, voir[Tutoriels de mise en route](getting-started-topnode.md). ## Création d'un projet à l'aide d'un plan La création d'un projet est la première étape pour pouvoir travailler ensemble. Vous pouvez utiliser un plan pour créer votre projet, qui créera également un référentiel source avec un exemple de code et un flux de travail qui créera et déploiera automatiquement votre code lorsque vous le modifiez. Dans ce didacticiel, nous allons vous présenter un projet créé à l'aide du plan d'**application d'une seule page**, mais vous pouvez suivre les procédures de tout projet comportant un référentiel source. Assurez-vous de choisir un rôle IAM ou d'ajouter un rôle IAM si vous n'en avez pas un lors de la création du projet. Nous vous recommandons d'utiliser le rôle **CodeCatalystWorkflowDevelopmentRole-*spaceName***de service pour ce projet. Si vous avez déjà un projet, vous pouvez passer à[Afficher les référentiels d'un projet](#source-getting-started-source-view). **Note** Seuls les utilisateurs dotés du rôle d'administrateur de **l'espace ou d'utilisateur** avancé peuvent créer des projets dans CodeCatalyst. Si vous n'avez pas ce rôle et que vous avez besoin d'un projet sur lequel travailler pour ce didacticiel, demandez à une personne possédant l'un de ces rôles de créer un projet pour vous et de vous ajouter au projet créé. Pour de plus amples informations, veuillez consulter [Octroi d'accès avec des rôles d'utilisateur](ipa-roles.md). **Pour créer un projet à l'aide d'un plan** 1. Dans la CodeCatalyst console, accédez à l'espace dans lequel vous souhaitez créer un projet. 1. Sur le tableau de bord de l'espace, choisissez **Créer un projet**. 1. Choisissez **Commencer par un plan**. **Astuce** Vous pouvez choisir d'ajouter un plan en indiquant à **Amazon Q** les exigences de votre projet pour qu'Amazon Q vous suggère un plan. Pour plus d’informations, consultez [Utiliser Amazon Q pour choisir un plan lors de la création d'un projet ou de l'ajout de fonctionnalités](getting-started-project-assistance.md#getting-started-project-assistance-create-apply-bp) et [Bonnes pratiques lors de l'utilisation d'Amazon Q pour créer des projets ou ajouter des fonctionnalités à l'aide de plans](projects-create.md#projects-create-amazon-q). Cette fonctionnalité n'est disponible que dans la région Ouest des États-Unis (Oregon). Cette fonctionnalité nécessite que les fonctionnalités d'IA génératives soient activées pour l'espace. 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. **Dans l'onglet **CodeCatalyst Blueprints** ou **Space Blueprints**, choisissez un plan, puis cliquez sur Next.** 1. Sous **Nommer votre projet**, entrez le nom que vous souhaitez attribuer à votre projet et les noms de ressources associés. Le nom doit être unique dans votre espace. 1. (Facultatif) Par défaut, le code source créé par le plan est stocké dans un CodeCatalyst référentiel. Vous pouvez également choisir de stocker le code source du plan dans un référentiel tiers. Pour de plus amples informations, veuillez consulter [Ajoutez des fonctionnalités aux projets avec des extensions dans CodeCatalystAjoutez des fonctionnalités aux projets avec des extensions](extensions.md). **Important** CodeCatalyst ne prend pas en charge la détection des modifications dans la branche par défaut pour les référentiels liés. Pour modifier la branche par défaut d'un dépôt lié, vous devez d'abord en dissocier CodeCatalyst, modifier la branche par défaut, puis la lier à nouveau. Pour de plus amples informations, veuillez consulter [Lier GitHub les référentiels, les référentiels Bitbucket, les référentiels de GitLab projets et les projets Jira dans CodeCatalyst](extensions-link.md). Il est recommandé de toujours s'assurer que vous disposez de la dernière version de l'extension avant de lier un dépôt. Procédez de l'une des manières suivantes en fonction du fournisseur de référentiel tiers que vous souhaitez utiliser : + **GitHub référentiels** : connectez un GitHub compte. Choisissez le menu déroulant **Avancé**, choisissez GitHub comme fournisseur de référentiel, puis choisissez le GitHub compte sur lequel vous souhaitez stocker le code source créé par le plan. **Note** Si vous connectez un GitHub compte, vous devez créer une connexion personnelle pour établir un mappage d'identité entre votre CodeCatalyst identité et votre GitHub identité. Pour plus d’informations, consultez [Connexions personnelles](concepts.md#personal-connection-concept) et [Accès aux GitHub ressources par le biais de connexions personnelles](ipa-settings-connections.md). + **Référentiels Bitbucket** : connectez un espace de travail Bitbucket. Choisissez le menu déroulant **Avancé**, choisissez Bitbucket comme fournisseur de référentiel, puis choisissez l'espace de travail Bitbucket dans lequel vous souhaitez stocker le code source créé par le plan. + **GitLab référentiels** : Connectez un GitLab utilisateur. Choisissez le menu déroulant **Avancé**, choisissez GitLab comme fournisseur de référentiel, puis choisissez l' GitLab utilisateur dans lequel vous souhaitez stocker le code source créé par le plan. 1. Sous **Ressources du projet**, configurez les paramètres du plan. Selon le plan, vous pouvez avoir la possibilité de nommer le nom du référentiel source. 1. (Facultatif) Pour afficher les fichiers de définition mis à jour en fonction des paramètres de projet sélectionnés, choisissez **Afficher le code ou Afficher** **le flux de travail** dans **Générer un aperçu du projet**. 1. (Facultatif) Choisissez **Afficher les détails** dans la fiche du plan pour afficher des détails spécifiques sur le plan, tels qu'un aperçu de l'architecture du plan, les connexions et autorisations requises, ainsi que le type de ressources créé par le plan. 1. Sélectionnez **Create a project (Créer un projet)**. La page d'aperçu du projet s'ouvre dès que vous créez un projet ou que vous acceptez une invitation à participer à un projet et que vous terminez le processus de connexion. La page de présentation d'un nouveau projet ne contient aucun problème en suspens ni aucune pull request. Vous pouvez éventuellement choisir de créer un problème et de vous l'attribuer. Vous pouvez également choisir d'inviter quelqu'un d'autre à rejoindre votre projet. Pour plus d’informations, consultez [Création d'un problème dans CodeCatalyst](issues-create-issue.md) et [Inviter un utilisateur à participer à un projet](projects-members.md#projects-members-add). ## Afficher les référentiels d'un projet En tant que membre d'un projet, vous pouvez consulter les référentiels sources du projet. Vous pouvez également choisir de créer des référentiels supplémentaires. Si une personne ayant le rôle d'**administrateur d'espace** a installé et configuré les **GitHub référentiels, les référentiels** **Bitbucket ou l'extension de **GitLab référentiels****, vous pouvez également ajouter des liens vers des référentiels tiers dans les GitHub comptes, les espaces de travail Bitbucket ou les utilisateurs configurés pour l'extension. GitLab Pour plus d’informations, consultez [Création d'un référentiel source](source-repositories-create.md) et [Démarrage rapide : installation d'extensions, connexion de fournisseurs et liaison de ressources dans CodeCatalyst](extensions-quickstart.md). **Note** Pour les projets créés avec le plan d'application d'une seule page, le nom par défaut du référentiel source contenant l'exemple de code est. ***spa-app*** **Pour accéder aux référentiels sources d'un projet** 1. Accédez à votre projet, puis effectuez l'une des opérations suivantes : + Sur la page de résumé de votre projet, choisissez le référentiel souhaité dans la liste, puis choisissez **Afficher le référentiel**. + Dans le volet de navigation, choisissez **Code**, puis sélectionnez **Référentiels sources**. Dans **Référentiels sources**, choisissez le nom du référentiel dans la liste. Vous pouvez filtrer la liste des référentiels en saisissant une partie du nom du référentiel dans la barre de filtre. 1. Sur la page d'accueil du référentiel, consultez le contenu du référentiel et les informations sur les ressources associées, telles que le nombre de pull requests et les flux de travail. Par défaut, le contenu de la branche par défaut est affiché. Vous pouvez modifier l'affichage en choisissant une autre branche dans la liste déroulante. La page de présentation du référentiel inclut des informations sur les flux de travail et les pull requests configurés pour les branches de ce référentiel et ses fichiers. Si vous venez de créer le projet, les flux de travail initiaux pour créer, tester et déployer le code seront toujours en cours d'exécution, car leur exécution prend quelques minutes. Vous pouvez consulter les flux de travail associés et leur statut en choisissant le numéro sous **Flux de travail associés**, mais cela ouvre la page **Flux** de travail dans **CI/CD**. Pour ce didacticiel, restez sur la page de présentation et explorez le code du référentiel. Le contenu du `README.md` fichier est affiché sur cette page sous les fichiers du référentiel. Dans **Fichiers**, le contenu de la branche par défaut est affiché. Vous pouvez modifier l'affichage du fichier pour afficher le contenu d'une autre branche si vous en avez une. Le `.codecatalyst` dossier contient le code utilisé pour d'autres parties du projet, tels que les fichiers YAML du flux de travail. Pour afficher le contenu des dossiers, cliquez sur la flèche située à côté du nom du dossier pour le développer. Par exemple, cliquez sur la flèche à côté `src` pour afficher les fichiers de l'application Web d'une seule page contenue dans ce dossier. Pour afficher le contenu d'un fichier, sélectionnez ce dernier dans la liste. Cela ouvre la fenêtre **Afficher les fichiers**, dans laquelle vous pouvez parcourir le contenu de plusieurs fichiers. Vous pouvez également modifier des fichiers uniques dans la console, mais pour modifier plusieurs fichiers, vous devez créer un environnement de développement. ## Création d’un environnement de développement Vous pouvez ajouter et modifier des fichiers dans un référentiel source dans la CodeCatalyst console Amazon. Toutefois, pour travailler efficacement avec plusieurs fichiers et branches, nous vous recommandons d'utiliser un environnement de développement ou de cloner le référentiel sur votre ordinateur local. Dans ce didacticiel, nous allons créer un AWS Cloud9 environnement de développement avec une branche nommée**develop**. Vous pouvez choisir un autre nom de branche, mais en nommant la branche**develop**, un flux de travail s'exécutera automatiquement pour générer et tester votre code lorsque vous créerez une pull request plus loin dans ce didacticiel. **Astuce** Si vous décidez de cloner un dépôt localement au lieu ou en plus d'utiliser un environnement de développement, assurez-vous que Git est installé sur votre ordinateur local ou que votre IDE inclut Git. Pour de plus amples informations, veuillez consulter [Configuration pour travailler avec les référentiels sources](source-setting-up.md). **Pour créer un environnement de développement avec une nouvelle branche** 1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Accédez au projet dans lequel vous souhaitez créer un environnement de développement. 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**, choisir **Référentiels sources** et choisir le référentiel pour lequel vous souhaitez créer un environnement de développement. 1. Sur la page d'accueil du référentiel, choisissez **Create Dev Environment**. 1. Choisissez un IDE compatible dans le menu déroulant. Pour plus d’informations, consultez [Environnements de développement intégrés pris en charge pour les environnements de développement](devenvironment-create.md#devenvironment-supported-ide). 1. Choisissez le référentiel à cloner, choisissez **Travailler dans une nouvelle branche**, entrez le nom de la **branche dans le champ Nom** de la branche et choisissez une branche à partir de laquelle créer la nouvelle branche dans le menu déroulant **Créer une branche depuis**. 1. Ajoutez éventuellement un alias pour l'environnement de développement. 1. Vous pouvez éventuellement cliquer sur le bouton **d'édition de la configuration de l'environnement** de développement pour modifier la configuration de calcul, de stockage ou de temporisation de l'environnement de développement. 1. Choisissez **Créer**. Pendant la création de votre environnement de développement, la colonne d'état de l'environnement de développement affichera **Démarrage**, et la colonne d'état affichera En **cours d'exécution** une fois l'environnement de développement créé. Un nouvel onglet s'ouvre avec votre environnement de développement dans l'IDE de votre choix. Vous pouvez modifier le code, valider et appliquer vos modifications. Une fois que vous avez créé l'environnement de développement, vous pouvez modifier des fichiers, valider vos modifications et les transférer vers la **test** branche. Pour ce didacticiel, modifiez le contenu entre les `

` balises du `App.tsx` fichier du `src` dossier afin de modifier le texte affiché sur la page Web. Validez et validez votre modification, puis revenez à l' CodeCatalyst onglet. ## Pour apporter et appliquer un changement à partir d'un environnement AWS Cloud9 de développement 1. Dans AWS Cloud9, développez le menu de navigation latéral pour parcourir les fichiers. `src`Développez et ouvrez`App.tsx`. 1. Modifiez le texte à l'intérieur des `

` balises. 1. Enregistrez le fichier, puis validez et appliquez vos modifications à l'aide du menu Git. Vous pouvez également, dans la fenêtre du terminal, valider et appliquer vos modifications à l'aide **git commit** des **git push** commandes et. ``` git commit -am "Making an example change" git push ``` **Astuce** Vous devrez peut-être remplacer les répertoires du terminal par le répertoire du référentiel Git avant de pouvoir exécuter correctement les commandes Git. ## Création d’une demande pull 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. Dans ce didacticiel, vous allez créer une pull request pour examiner les modifications que vous avez apportées à la *test* branche par rapport à la branche **principale**. La création d'une pull request dans un projet créé à l'aide d'un modèle lancera également l'exécution des flux de travail associés, le cas échéant. **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. Vous pouvez consulter les informations relatives aux flux de travail associés lancés par la création de cette pull request en choisissant **Vue d'ensemble**, puis en consultant les informations dans la zone des **détails de la demande d'extraction** sous **Exécutions du flux** de travail. Pour afficher le flux de travail exécuté, choisissez l'exécution. **Astuce** Si vous avez donné un autre nom à votre branche**develop**, aucun flux de travail ne s'exécutera automatiquement pour créer et tester vos modifications. Si vous souhaitez configurer cela, modifiez le fichier YAML du **onPullRequestBuildAndTest**flux de travail. Pour de plus amples informations, veuillez consulter [Création d'un flux de travail](workflows-create-workflow.md). Vous pouvez commenter cette pull request et demander aux autres membres du projet de le faire. Vous pouvez également choisir d'ajouter ou de modifier des réviseurs facultatifs ou obligatoires. Vous pouvez choisir d'apporter d'autres modifications à la branche source du référentiel et voir comment ces modifications validées créent des révisions pour la pull request. Pour plus d'informations, reportez-vous aux [Mise à jour d’une demande pull](pull-requests-update.md) sections[Révision d’une demande pull](pull-requests-review.md),[Révision du code à l'aide de pull requests sur Amazon CodeCatalyst](source-pull-requests.md), et[Afficher le statut et les détails de l'exécution du flux de travail](workflows-view-run.md). ## Fusion d’une demande pull Une fois qu'une pull request a été examinée et approuvée par les réviseurs requis, vous pouvez fusionner sa branche source avec la branche de destination dans la CodeCatalyst console. La fusion d'une pull request lancera également une série de modifications via tous les flux de travail associés à la branche de destination. Dans ce didacticiel, vous allez fusionner la branche de test avec la branche principale, ce qui lancera une exécution du **onPushToMainDeployPipeline**flux de travail. **Pour fusionner une pull request (console)** 1. Dans **Pull requests**, choisissez la pull request que vous avez créée à l'étape précédente. Dans la pull request, choisissez **Merge**. 1. Choisissez parmi les stratégies de fusion disponibles pour la pull request. **Sélectionnez ou désélectionnez éventuellement l'option permettant de supprimer la branche source après avoir fusionné la pull request, puis choisissez Merge.** Une fois la fusion terminée, le statut de la pull request passe à **Merged** et n'apparaît plus dans la vue par défaut des pull requests. La vue par défaut affiche les pull requests dont le statut est **Ouvert**. Vous pouvez toujours consulter une pull request fusionnée, mais vous ne pouvez pas l'approuver ni modifier son statut. **Note** Si le bouton **Fusionner** n'est pas actif ou si le libellé **Non fusionnable s'affiche**, cela signifie que le réviseur requis n'a 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 section **Vue d'ensemble**, dans la zone des **détails de la pull request**. Si tous les réviseurs requis ont approuvé la pull request mais que le bouton **Fusionner** n'est toujours pas actif, il se peut que vous rencontriez un conflit de fusion ou que vous ayez dépassé le quota de stockage pour l'espace. Vous pouvez résoudre les conflits de fusion pour la branche de destination dans un environnement de développement, appliquer les modifications, puis fusionner la pull request, ou vous pouvez résoudre les conflits et fusionner localement, puis transférer le commit contenant la fusion vers CodeCatalyst. Pour plus d'informations, consultez [Fusion d'une pull request (Git)](pull-requests-merge.md#pull-requests-merge-git) votre documentation Git. ## Afficher le code déployé Il est maintenant temps de consulter le code initialement déployé qui se trouvait dans la branche par défaut, ainsi que les modifications que vous avez fusionnées une fois qu'elles ont été automatiquement créées, testées et déployées. **Pour ce faire, vous pouvez revenir à la page d'aperçu du référentiel et choisir le numéro à côté de l'icône des flux de travail associés, ou dans le volet de navigation, choisir **CI/CD**, puis choisir Workflows.** **Pour afficher le code déployé** 1. Dans **Workflows**, dans`onPushToMainDeployPipeline`, développez **Recent runs**. **Note** Il s'agit du nom par défaut du flux de travail pour les projets créés avec le plan d'**application d'une seule page**. 1. La dernière exécution est celle lancée par la validation de votre pull request fusionnée dans la `main` branche et affichera probablement le statut **En cours**. Choisissez une exécution terminée avec succès dans la liste pour afficher les détails de cette exécution. 1. Choisissez **Variables**. Copiez la valeur de **AppURL**. Il s'agit de l'URL de l'application Web à page unique déployée. Ouvrez un nouvel onglet de navigateur et collez la valeur pour afficher le code créé et déployé. Laissez l'onglet ouvert. 1. Revenez à la liste des exécutions du flux de travail et attendez que l'exécution la plus récente soit terminée. Lorsque c'est le cas, retournez à l'onglet que vous avez ouvert pour afficher l'application Web et actualiser votre navigateur. Vous devriez voir les modifications que vous avez apportées dans votre pull request fusionnée. ## Nettoyage des ressources Une fois que vous aurez exploré l'utilisation d'un référentiel source et d'une pull request, vous souhaiterez peut-être supprimer les ressources dont vous n'avez pas besoin. Vous ne pouvez pas supprimer les pull requests, mais vous pouvez les fermer. Vous pouvez supprimer toutes les branches que vous avez créées. Si vous n'avez plus besoin du référentiel source ou du projet, vous pouvez également supprimer ces ressources. Pour plus d'informations, consultez [Supprimer un référentiel source](source-repositories-delete.md) et [Suppression d’un projet](projects-delete.md). # Stockage du code source dans des référentiels pour un projet dans CodeCatalyst Un référentiel source est l'endroit où vous stockez en toute sécurité le code et les fichiers de votre projet. Il stocke également l'historique de vos sources, depuis le premier commit jusqu'aux dernières modifications. Si vous choisissez un plan qui inclut un référentiel source, ce référentiel contient également les fichiers de configuration et d'autres informations relatives aux flux de travail et aux notifications du projet. Ces informations de configuration sont stockées dans un dossier nommé **.codecatalyst**. Vous pouvez créer un référentiel source CodeCatalyst soit en créant un projet avec un plan qui crée un référentiel source dans le cadre de la création d'un projet, soit en créant un référentiel source dans un projet existant. Les utilisateurs du projet verront et pourront utiliser automatiquement les référentiels que vous créez pour un projet. Vous pouvez également choisir de lier un dépôt Git hébergé sur GitHub Bibucket ou GitLab à votre projet. Lorsque vous le faites, les utilisateurs de votre projet peuvent consulter et accéder à ce référentiel lié dans la liste des référentiels du projet. **Note** Avant de lier le référentiel, vous devez installer l'extension pour le service qui l'héberge. Vous ne pouvez pas lier un dépôt archivé. Bien que vous puissiez lier un dépôt vide, vous ne pouvez pas l'utiliser CodeCatalyst tant que vous ne l'avez pas initialisé avec un commit initial qui crée une branche par défaut. Pour de plus amples informations, veuillez consulter [Installation d'une extension dans un espace](install-extension.md). Par défaut, un référentiel source est partagé avec les autres membres de votre CodeCatalyst projet Amazon. Vous pouvez créer des référentiels de sources supplémentaires pour un projet ou lier des référentiels au projet. Tous les membres d'un projet peuvent afficher, ajouter, modifier et supprimer des fichiers et des dossiers dans les référentiels sources du projet. Pour travailler rapidement sur le code d'un référentiel source, vous pouvez créer un environnement de développement qui clone un référentiel spécifique et y ajouter des branches dans lequel vous pouvez travailler sur le code dans l'environnement de développement intégré (IDE) que vous avez choisi pour l'environnement de développement. Vous pouvez cloner un dépôt source sur votre ordinateur local et extraire et transférer les modifications entre votre dépôt local et le dépôt distant. CodeCatalyst Vous pouvez également travailler avec les référentiels sources en configurant l'accès à ceux-ci dans votre IDE préféré, à condition que cet IDE prenne en charge la gestion des informations d'identification. Les noms des référentiels doivent être uniques au sein d'un CodeCatalyst projet. **Topics** + [Création d'un référentiel source](source-repositories-create.md) + [Clonage d'un dépôt Git existant dans un dépôt source](source-repositories-add-existing.md) + [Lier un référentiel source](source-repositories-link.md) + [Affichage d’un référentiel source](source-repositories-view.md) + [Modification des paramètres d'un référentiel source](source-repositories-edit.md) + [Clonage d’un référentiel source](source-repositories-clone.md) + [Supprimer un référentiel source](source-repositories-delete.md) # Création d'un référentiel source Lorsque vous créez un projet à l'aide d'un plan sur Amazon CodeCatalyst, vous CodeCatalyst créez un référentiel de sources. Ce référentiel source contient un exemple de code en plus des informations de configuration pour les flux de travail et les autres ressources créées pour vous. Il s'agit de la méthode recommandée pour commencer à utiliser les référentiels dans CodeCatalyst. Vous pouvez choisir de créer des référentiels pour un projet. Ces référentiels contiendront un fichier **README.md** que vous pourrez modifier ou supprimer à tout moment. En fonction de vos choix lors de la création d'un référentiel source, les référentiels peuvent également contenir un `.gitignore` fichier. Si vous souhaitez cloner un dépôt Git existant dans un dépôt CodeCatalyst source, pensez plutôt à créer un dépôt vide. Ce dépôt ne pourra pas être utilisé CodeCatalyst tant que vous n'y ajouterez pas de contenu, ce que vous pouvez faire à l'aide de quelques commandes Git simples. Vous pouvez également ajouter du contenu au référentiel vide directement depuis la CodeCatalyst console. Vous pouvez également lier un dépôt source dans un fournisseur de dépôt Git compatible. Pour de plus amples informations, veuillez consulter [Lier un référentiel source](source-repositories-link.md). **Pour créer un référentiel source** 1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Accédez à votre projet. 1. Dans le volet de navigation, choisissez **Code**, puis sélectionnez **Référentiels sources**. 1. Choisissez **Ajouter un référentiel**, puis sélectionnez **Créer un référentiel**. 1. Dans **Nom du référentiel**, saisissez le nom du référentiel. Dans ce guide, nous utilisons un autre nom*codecatalyst-source-repository*, mais vous pouvez en choisir un autre. Les noms des référentiels doivent être uniques au sein d'un projet. Pour plus d'informations sur les exigences relatives aux noms de référentiels, consultez[Quotas pour les référentiels sources dans CodeCatalyst](source-quotas.md). 1. (Facultatif) Dans **Description**, ajoutez une description du référentiel afin d'aider les autres utilisateurs du projet à comprendre à quoi sert le référentiel. 1. Choisissez **Créer un référentiel (par défaut)**. Cette option crée un référentiel qui inclut une branche par défaut et un fichier README.md. Contrairement à un dépôt vide, vous pouvez l'utiliser dès sa création. 1. Dans la **branche par défaut**, laissez le nom *principal*, sauf si vous avez une raison d'en choisir un autre. Les exemples présentés dans ce guide utilisent tous le nom *main* pour la branche par défaut. 1. (Facultatif) Ajoutez un `.gitignore` fichier correspondant au type de code que vous souhaitez envoyer. 1. Choisissez **Créer**. **Note** CodeCatalyst ajoute un `README.md` fichier à votre dépôt lorsque vous le créez. CodeCatalystcrée également un commit initial pour le dépôt dans une branche par défaut nommée **main**. Vous pouvez modifier ou supprimer le fichier README.md, mais vous ne pouvez pas supprimer la branche par défaut. **Pour créer un référentiel source vide** 1. Dans la CodeCatalyst console, accédez au projet dans lequel vous souhaitez créer un référentiel vide. 1. Sur la page de résumé de votre projet, dans **Référentiels sources**, choisissez **Ajouter un référentiel**, puis sélectionnez **Créer un référentiel**. Dans le volet de navigation, vous pouvez également choisir **Code**, puis **Référentiels sources**. Choisissez **Ajouter un référentiel**, puis sélectionnez **Créer un référentiel**. 1. Dans **Nom du référentiel**, saisissez le nom du référentiel. Dans ce guide, nous utilisons un autre nom*codecatalyst-source-repository*, mais vous pouvez en choisir un autre. Les noms des référentiels doivent être uniques au sein d'un projet. Pour plus d'informations sur les exigences relatives aux noms de référentiels, consultez[Quotas pour les référentiels sources dans CodeCatalyst](source-quotas.md). 1. (Facultatif) Dans **Description**, ajoutez une description du référentiel afin d'aider les autres utilisateurs du projet à comprendre à quoi sert le référentiel. 1. Choisissez **Créer un référentiel vide**, puis sélectionnez **Créer**. # Clonage d'un dépôt Git existant dans un dépôt source Vous pouvez cloner un dépôt Git existant vers un référentiel source vide sur Amazon CodeCatalyst. Il s'agit d'un moyen rapide de démarrer CodeCatalyst avec du code précédemment hébergé dans un autre fournisseur de dépôt Git. Vous pouvez cloner le contenu du référentiel en créant un clone miroir, puis en poussant le miroir vers CodeCatalyst. Sinon, si vous disposez d'un dépôt local du référentiel dont vous souhaitez ajouter le contenu CodeCatalyst, vous pouvez ajouter le référentiel CodeCatalyst source en tant qu'autre répertoire distant au dépôt local, puis le transférer vers le référentiel source vide. Les deux approches sont également valables. L'utilisation d'un clone miroir permet non seulement de cartographier les branches, mais également de cartographier toutes les références. Il s'agit d'un moyen simple et propre de créer une copie de travail du référentiel dans CodeCatalyst. L'ajout d'une télécommande à un dépôt local pointant vers un dépôt CodeCatalyst source vide ajoutera le contenu du référentiel CodeCatalyst, mais vous permettra également d'effectuer des push depuis le dépôt local vers le référentiel CodeCatalyst source et le référentiel distant Git d'origine. Cela peut être utile si vous souhaitez conserver le code dans différents référentiels distants, mais cela peut entraîner des conflits si d'autres développeurs ne valident le code que sur l'une des télécommandes. Les procédures suivantes utilisent des commandes Git de base pour accomplir cette tâche. Il existe de nombreuses manières d'accomplir des tâches dans Git, notamment le clonage. Pour plus d'informations, consultez la [documentation Git.](https://git-scm.com/docs/git-clone) **Important** Vous devez créer un référentiel vide CodeCatalyst avant de pouvoir y cloner du contenu. Vous devez également disposer d'un jeton d'accès personnel. Pour plus d’informations, consultez [Pour créer un référentiel source vide](source-repositories-create.md#source-repositories-create-empty) et [Créez un jeton d'accès personnel](source-setting-up.md#source-setting-up-pat). **À utiliser `git clone --mirror` pour cloner un dépôt Git existant dans CodeCatalyst** 1. Dans la CodeCatalyst console, accédez au projet dans lequel vous avez créé un référentiel vide. 1. Sur la page de résumé de votre projet, choisissez le référentiel vide dans la liste, puis choisissez **Afficher le référentiel**. Dans le volet de navigation, vous pouvez également choisir **Code**, puis **Référentiels sources**. Choisissez le nom du référentiel vide dans la liste des référentiels sources du projet. 1. Copiez l'URL du clone HTTPS du référentiel vide. Vous en aurez besoin pour transférer le clone miroir. Par exemple, si vous avez nommé le référentiel source MyExampleRepo dans le MyExampleProject projet dans l' ExampleCorp espace et que votre nom d'utilisateur est le même LiJuan, l'URL de votre clone peut ressembler à ce qui suit : ``` https://LiJuan@git.us-west-2.codecatalyst.aws/v1/ExampleCorp/MyExampleProject/MyExampleRepo ``` 1. Dans une ligne de commande ou une fenêtre de terminal, utilisez la `git clone --mirror` commande pour créer un clone miroir du dépôt Git dans lequel vous souhaitez effectuer le clonage CodeCatalyst. Par exemple, si vous souhaitez créer un clone miroir du référentiel codecatalyst-blueprints dans GitHub, vous devez entrer la commande suivante : ``` git clone --mirror https://github.com/aws/codecatalyst-blueprints.git ``` 1. Placez-vous dans le répertoire où vous avez créé le clone. ``` cd codecatalyst-blueprints.git ``` 1. Exécutez la **git push** commande en spécifiant l'URL et le nom du référentiel CodeCatalyst source de destination ainsi que l'**--all**option. (Il s'agit de l'URL que vous avez copiée à l'étape 3.) Par exemple : ``` git push https://LiJuan@git.us-west-2.codecatalyst.aws/v1/ExampleCorp/MyExampleProject/MyExampleRepo --all ``` **Pour ajouter une télécommande et transférer un dépôt local dans CodeCatalyst** 1. Dans la CodeCatalyst console, accédez au projet dans lequel vous avez créé un référentiel vide. 1. Sur la page de résumé de votre projet, choisissez le référentiel vide dans la liste, puis choisissez **Afficher le référentiel**. Dans le volet de navigation, vous pouvez également choisir **Code**, puis **Référentiels sources**. Choisissez le nom du référentiel vide dans la liste des référentiels sources du projet. 1. Copiez l'URL du clone HTTPS du référentiel vide. Vous en aurez besoin pour transférer le clone miroir. Par exemple, si vous avez nommé le référentiel source MyExampleRepo dans le MyExampleProject projet dans l' ExampleCorp espace et que votre nom d'utilisateur est le même LiJuan, l'URL de votre clone peut ressembler à ce qui suit : ``` https://LiJuan@git.us-west-2.codecatalyst.aws/v1/ExampleCorp/MyExampleProject/MyExampleRepo ``` 1. Dans une ligne de commande ou une fenêtre de terminal, remplacez les répertoires par le dépôt local vers lequel vous souhaitez envoyer le message. CodeCatalyst 1. Exécutez la commande git remote -v pour voir les télécommandes existantes pour le dépôt local. Par exemple, si vous clonez un dépôt local d'un AWS CodeCommit dépôt nommé **MyDemoRepo** dans la région USA Est (Ohio), le résultat de votre commande peut ressembler à ceci : ``` origin https://git-codecommit.us-east-2.amazonaws.com/v1/repos/MyDemoRepo (fetch) origin https://git-codecommit.us-east-2.amazonaws.com/v1/repos/MyDemoRepo (push) ``` Copiez l'URL distante si vous souhaitez continuer à utiliser le référentiel. 1. Utilisez la `git remote remove` commande pour supprimer le CodeCommit dépôt URLs pour fetch et push pour origin : ``` git remote remove origin ``` 1. Utilisez la commande **git remote add** pour ajouter l'URL du dépôt CodeCatalyst source comme source à récupérer et à envoyer à distance pour votre dépôt local. Par exemple : ``` git remote add origin https://LiJuan@git.us-west-2.codecatalyst.aws/v1/ExampleCorp/MyExampleProject/MyExampleRepo ``` Cela remplace l'URL push du CodeCommit dépôt par l'URL du référentiel CodeCatalyst source, mais ne modifie pas l'URL de récupération. Ainsi, si vous réexécutez la commande git remote -v, vous verrez que vous êtes en train d'extraire (récupérer) du code depuis le dépôt CodeCommit distant, mais que vous êtes configuré pour transférer les modifications de votre dépôt local vers le CodeCatalyst dépôt source : ``` origin https://git-codecommit.us-east-2.amazonaws.com/v1/repos/MyDemoRepo (fetch) origin https://LiJuan@git.us-west-2.codecatalyst.aws/v1/ExampleCorp/MyExampleProject/MyExampleRepo (push) ``` Vous pouvez éventuellement ajouter à nouveau l'URL CodeCommit distante si vous souhaitez envoyer un message aux deux référentiels à l'aide de la `git remote set-url` commande suivante : ``` git remote set-url --add --push origin https://git-codecommit.us-east-2.amazonaws.com/v1/repos/MyDemoRepo ``` 1. Exécutez la `git push` commande pour transférer le dépôt local vers toutes les télécommandes push configurées. Vous pouvez également exécuter la **git push -u -origin** commande en spécifiant l'**--all**option permettant de transférer le dépôt local vers les deux référentiels. Par exemple : ``` git push -u -origin --all ``` **Astuce** Selon votre version de Git, --all peut ne pas fonctionner pour transférer toutes les branches du dépôt local vers le dépôt vide. Vous devrez peut-être vérifier et pousser chaque branche séparément. # Lier un référentiel source Lorsque vous liez un référentiel source à un projet, vous pouvez inclure des référentiels dotés d'une CodeCatalyst extension pour le service hébergeant le référentiel, si cette extension est installée pour votre espace. Seuls les utilisateurs dotés du rôle d'administrateur de l'espace peuvent installer des extensions. Une fois l'extension installée, vous pouvez créer un lien vers les référentiels configurés pour être accessibles par cette extension. Pour plus d'informations, consultez [Installation d'une extension dans un espace](install-extension.md) ou suivez[Lier GitHub les référentiels, les référentiels Bitbucket, les référentiels de GitLab projets et les projets Jira dans CodeCatalyst](extensions-link.md). **Important** Après avoir installé une extension de référentiel, le code de tous les référentiels auxquels vous créez un lien CodeCatalyst sera indexé et stocké. CodeCatalyst Cela rendra le code consultable dans. CodeCatalyst Pour mieux comprendre la protection des données de votre code lorsque vous utilisez des référentiels liés dans CodeCatalyst, consultez la section [Protection des données](https://docs.aws.amazon.com/codecatalyst/latest/userguide/data-protection.html) dans le *guide de l' CodeCatalyst utilisateur Amazon*. Vous ne pouvez lier un dépôt qu'à un seul projet dans un espace. Vous ne pouvez pas lier un dépôt archivé. Bien que vous puissiez lier un dépôt vide, vous ne pouvez pas l'utiliser CodeCatalyst tant que vous ne l'avez pas initialisé avec un commit initial qui crée une branche par défaut. En outre : + Un GitHub dépôt, un dépôt Bitbucket ou un dépôt de GitLab projet ne peut être lié qu'à un seul CodeCatalyst projet dans un espace. + Vous ne pouvez pas utiliser de référentiels vides ou archivés, de GitHub référentiels Bitbucket ou de référentiels de projets avec des GitLab projets. CodeCatalyst + Vous ne pouvez pas lier un GitHub dépôt, un dépôt Bitbucket ou un dépôt de GitLab projet portant le même nom qu'un dépôt d'un CodeCatalyst projet. + L'extension **GitHub Repositories** n'est pas compatible avec les référentiels GitHub Enterprise Server. + L'extension **Bitbucket Repositories** n'est pas compatible avec les référentiels Bitbucket Data Center. + L'extension **GitLab Repositories** n'est pas compatible avec les référentiels de projets GitLab autogérés. + Vous ne pouvez pas utiliser les fonctionnalités **Rédiger une description pour moi** ou **Résumer les commentaires** avec des référentiels liés. Ces fonctionnalités ne sont disponibles que dans les pull requests in CodeCatalyst. Bien que vous puissiez lier un GitHub dépôt, un dépôt Bitbucket ou un dépôt de GitLab projet en tant que **contributeur**, vous ne pouvez dissocier un référentiel tiers qu'en tant qu'administrateur de l'**espace ou administrateur** du **projet**. Pour de plus amples informations, veuillez consulter [Dissociation GitHub des référentiels, des référentiels Bitbucket, des référentiels de projets et des GitLab projets Jira dans CodeCatalyst](extensions-unlink.md). **Important** CodeCatalyst ne prend pas en charge la détection des modifications dans la branche par défaut pour les référentiels liés. Pour modifier la branche par défaut d'un dépôt lié, vous devez d'abord en dissocier CodeCatalyst, modifier la branche par défaut, puis la lier à nouveau. Pour de plus amples informations, veuillez consulter [Lier GitHub les référentiels, les référentiels Bitbucket, les référentiels de GitLab projets et les projets Jira dans CodeCatalyst](extensions-link.md). Il est recommandé de toujours s'assurer que vous disposez de la dernière version de l'extension avant de lier un dépôt. **Pour lier un référentiel source** 1. Accédez au projet auquel vous souhaitez lier un référentiel. **Note** Avant de pouvoir lier un référentiel, un utilisateur ayant le rôle d'administrateur de Space doit d'abord installer l'extension pour le fournisseur qui héberge le référentiel. Pour de plus amples informations, veuillez consulter [Installation d'une extension dans un espace](install-extension.md). 1. Dans le volet de navigation, choisissez **Code**, puis sélectionnez **Référentiels sources**. 1. Choisissez **Ajouter un référentiel**, puis choisissez **Lier le référentiel**. 1. Dans le menu déroulant **Fournisseur de référentiel**, choisissez l'un des fournisseurs de référentiels tiers suivants : **GitHub**ou **Bitbucket**. 1. Procédez de l'une des manières suivantes en fonction du fournisseur de référentiel tiers que vous avez choisi de lier : + **GitHub référentiels** : liez un GitHub référentiel. 1. Dans le menu déroulant du **GitHub compte**, choisissez le GitHub compte qui contient le référentiel que vous souhaitez associer. 1. Dans le menu déroulant du **GitHub dépôt**, choisissez le GitHub compte auquel vous souhaitez associer votre CodeCatalyst projet. 1. (Facultatif) Si aucun GitHub référentiel ne figure dans la liste des référentiels, il se peut qu'il n'ait pas été configuré pour l'accès au référentiel dans l' CodeCatalyst application Amazon dans GitHub. Vous pouvez configurer les GitHub référentiels dans CodeCatalyst lesquels le compte connecté peut être utilisé. 1. Accédez à votre [GitHub](https://github.com/)compte, sélectionnez **Paramètres**, puis **Applications**. 1. Dans l'onglet ** GitHub Applications installées**, choisissez **Configurer** pour l' CodeCatalyst application Amazon. 1. Procédez de l'une des manières suivantes pour configurer l'accès aux GitHub référentiels auxquels vous souhaitez créer un lien : CodeCatalyst + Pour fournir un accès à tous les référentiels actuels et futurs, choisissez **Tous les référentiels**. + Pour fournir un accès à des référentiels spécifiques, choisissez Ne **sélectionner que les référentiels**, choisissez le menu déroulant **Sélectionner les référentiels**, puis choisissez un référentiel que vous souhaitez autoriser à créer des liens. CodeCatalyst + **Référentiels Bitbucket** : liez un dépôt Bitbucket. 1. Dans le menu déroulant de l'**espace de travail Bitbucket**, choisissez l'espace de travail Bitbucket qui contient le référentiel que vous souhaitez lier. 1. Dans le menu déroulant du **dépôt Bitbucket**, choisissez le dépôt Bitbucket auquel vous souhaitez associer votre projet. CodeCatalyst **Astuce** Si le nom du dépôt est grisé, vous ne pouvez pas lier ce dépôt car il a déjà été lié à un autre projet sur Amazon CodeCatalyst. 1. Choisissez **Lier**. Si vous ne souhaitez plus utiliser de GitHub dépôt, de dépôt Bitbucket ou de dépôt de GitLab projet dans CodeCatalyst, vous pouvez le dissocier d'un CodeCatalyst projet. Lorsqu'un référentiel est dissocié, les événements de ce référentiel ne démarrent pas les exécutions de flux de travail et vous ne pourrez pas utiliser ce référentiel avec les environnements de CodeCatalyst développement. Pour de plus amples informations, veuillez consulter [Dissociation GitHub des référentiels, des référentiels Bitbucket, des référentiels de projets et des GitLab projets Jira dans CodeCatalyst](extensions-unlink.md). # Affichage d’un référentiel source Vous pouvez consulter les référentiels de sources associés à un projet sur Amazon CodeCatalyst. Pour les référentiels sources dans CodeCatalyst, la page de présentation d'un référentiel fournit un aperçu rapide des informations et des activités dans ce référentiel, notamment : + Description du référentiel, le cas échéant + Le nombre de branches dans le référentiel + Le nombre de pull requests ouvertes pour le référentiel + Le nombre de flux de travail associés pour le référentiel + Les fichiers et dossiers de la branche par défaut, ou de la branche que vous choisissez + Le titre, l'auteur et la date du dernier commit dans la branche affichée + Le contenu du fichier README.md affiché dans Markdown, si un fichier README.md est inclus Cette page fournit également des liens vers les commits, les branches et les pull requests du référentiel, ainsi qu'un moyen rapide d'ouvrir, de visualiser et de modifier des fichiers individuels. **Note** Vous ne pouvez pas afficher ces informations sur les référentiels liés dans la CodeCatalyst console. Pour afficher des informations sur les référentiels liés, cliquez sur le lien dans la liste des référentiels pour ouvrir ce référentiel dans le service qui l'héberge. **Pour accéder aux référentiels sources d'un projet** 1. Accédez à votre projet, puis effectuez l'une des opérations suivantes : + Sur la page de résumé de votre projet, choisissez le référentiel souhaité dans la liste, puis choisissez **Afficher le référentiel**. + Dans le volet de navigation, choisissez **Code**, puis sélectionnez **Référentiels sources**. Dans **Référentiels sources**, choisissez le nom du référentiel dans la liste. Vous pouvez filtrer la liste des référentiels en saisissant une partie du nom du référentiel dans la barre de filtre. 1. Sur la page d'accueil du référentiel, consultez le contenu du référentiel et les informations sur les ressources associées, telles que le nombre de pull requests et les flux de travail. Par défaut, le contenu de la branche par défaut est affiché. Vous pouvez modifier l'affichage en choisissant une autre branche dans la liste déroulante. **Astuce** Vous pouvez également accéder rapidement aux référentiels de votre projet en choisissant **Voir le code du projet** sur la page de résumé du projet. # Modification des paramètres d'un référentiel source Vous pouvez gérer les paramètres de votre référentiel, notamment en modifiant la description d'un référentiel, en choisissant la branche par défaut, en créant et en gérant des règles de branche, ainsi qu'en créant et en gérant des règles d'approbation pour les pull requests CodeCatalyst. Cela peut aider les membres du projet à comprendre à quoi sert le référentiel et vous aider à appliquer les meilleures pratiques et les meilleurs processus utilisés par l'équipe. **Note** Vous ne pouvez pas modifier le nom d'un dépôt source. Vous ne pouvez pas modifier le nom, la description ou les autres informations d'un référentiel lié dans CodeCatalyst. Pour modifier les informations relatives à un référentiel lié, vous devez les modifier dans le fournisseur qui héberge le référentiel lié. Pour plus d'informations, consultez la documentation du service qui héberge le référentiel lié. **Pour modifier les paramètres d'un référentiel** 1. Dans la CodeCatalyst console, accédez au projet qui contient le référentiel source dont vous souhaitez modifier les paramètres. 1. Sur la page de résumé de votre projet, choisissez le référentiel souhaité dans la liste, puis choisissez **Afficher le référentiel**. Dans le volet de navigation, vous pouvez également choisir **Code**, puis **Référentiels sources**. Choisissez le nom du référentiel dans la liste des référentiels sources du projet. 1. Sur la page d'aperçu du référentiel, choisissez **Plus**, puis sélectionnez **Gérer les paramètres**. 1. Effectuez une ou plusieurs des actions suivantes : + Modifiez la description du référentiel, puis choisissez **Enregistrer**. + Pour modifier la branche par défaut du référentiel, dans **Branche par défaut**, choisissez **Modifier**. Pour de plus amples informations, veuillez consulter [Gestion de la branche par défaut d'un dépôt](source-branches-default-branch.md). + Pour ajouter, supprimer ou modifier une règle indiquant les rôles du projet autorisés à effectuer certaines actions dans une branche, dans **Règles de branche**, sélectionnez **Modifier**. Pour de plus amples informations, veuillez consulter [Gérer les actions autorisées pour une branche à l'aide de règles de branche](source-branches-branch-rules.md). + **Pour ajouter, supprimer ou modifier une règle d'approbation pour la fusion des pull requests vers une branche, dans **Règles d'approbation**, choisissez Modifier.** Pour de plus amples informations, veuillez consulter [Gestion des exigences relatives à la fusion d'une pull request avec les règles d'approbation](source-pull-requests-approval-rules.md). # Clonage d’un référentiel source Pour travailler efficacement avec plusieurs fichiers, branches et validations dans les référentiels sources, clonez le référentiel source sur votre ordinateur local et utilisez un client Git ou un environnement de développement intégré (IDE) pour apporter des modifications. Validez et transférez vos modifications dans le référentiel source afin de gérer des CodeCatalyst fonctionnalités telles que les problèmes et les pull requests. Vous pouvez également choisir de créer un environnement de développement pour travailler sur le code. La création d'un environnement de développement clone automatiquement le référentiel et la branche que vous spécifiez dans l'environnement de développement. **Note** Vous ne pouvez pas cloner des référentiels liés dans la CodeCatalyst console ou créer des environnements de développement pour ceux-ci. Pour cloner un dépôt lié localement, cliquez sur le lien dans la liste des référentiels pour ouvrir ce référentiel dans le service qui l'héberge, puis clonez-le. Pour plus d'informations, consultez la documentation du service qui héberge le référentiel lié. **Pour créer un environnement de développement à partir d'un référentiel source** 1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Dans le volet de navigation, choisissez **Code**, puis sélectionnez **Référentiels sources**. 1. Choisissez le référentiel source dans lequel vous souhaitez travailler sur le code. 1. Choisissez **Create Dev Environment**. 1. Choisissez un IDE compatible dans le menu déroulant. Pour plus d’informations, consultez [Environnements de développement intégrés pris en charge pour les environnements de développement](devenvironment-create.md#devenvironment-supported-ide). 1. Effectuez l’une des actions suivantes : + Choisissez **Travailler dans une branche existante**, puis choisissez une branche dans le menu déroulant **Branche existante**. + Choisissez **Travailler dans une nouvelle branche**, entrez un nom de branche dans le champ **Nom de la branche** et choisissez une branche à partir de laquelle créer la nouvelle branche dans le menu déroulant **Créer une branche à partir de**. 1. Ajoutez éventuellement un nom pour l'environnement de développement ou modifiez sa configuration. 1. Choisissez **Créer**. **Pour cloner un référentiel source** 1. Accédez à votre projet. 1. Sur la page de résumé de votre projet, choisissez le référentiel souhaité dans la liste, puis choisissez **Afficher le référentiel**. Dans le volet de navigation, vous pouvez également choisir **Code**, puis **Référentiels sources**. Choisissez le nom du référentiel dans la liste des référentiels sources du projet. Vous pouvez filtrer la liste des référentiels en saisissant une partie du nom du référentiel dans la barre de filtre. 1. 1. Choisissez **Cloner le référentiel**. Copiez l'URL du clone du référentiel. **Note** Si vous n'avez pas de jeton d'accès personnel (PAT), choisissez **Create token**. Copiez le jeton et enregistrez-le dans un emplacement sécurisé. Vous utiliserez ce PAT lorsque votre client Git ou votre environnement de développement intégré (IDE) vous demandera de saisir un mot de passe. 1. Effectuez l’une des actions suivantes : + Pour cloner un dépôt sur votre ordinateur local, ouvrez un terminal ou une ligne de commande et exécutez la **git clone** commande avec l'URL du clone après la commande. Par exemple : ``` git clone https://LiJuan@git.us-west-2.codecatalyst.aws/v1/ExampleCorp/MyExampleProject/MyExampleRepo ``` Lorsque vous êtes invité à saisir un mot de passe, collez le PAT que vous avez enregistré précédemment. **Note** Si votre système d'exploitation assure la gestion des informations d'identification ou si vous avez installé un système de gestion des informations d'identification, vous ne devez fournir le PAT qu'une seule fois. Sinon, vous devrez peut-être fournir le PAT pour chaque opération Git. La meilleure pratique consiste à vous assurer que votre système de gestion des accréditations stocke votre PAT en toute sécurité. N'incluez pas le PAT dans la chaîne URL du clone. + Pour cloner un dépôt à l'aide d'un IDE, suivez la documentation de votre IDE. Choisissez l'option permettant de cloner un dépôt Git et de fournir l'URL. Lorsque vous êtes invité à saisir un mot de passe, indiquez le PAT. # Supprimer un référentiel source Si un référentiel source pour un CodeCatalyst projet Amazon n'est plus nécessaire, vous pouvez le supprimer. La suppression d'un référentiel source entraîne également la suppression de toutes les informations de projet stockées dans le référentiel. Si des flux de travail dépendent du référentiel source, ils seront supprimés de la liste des flux de travail du projet une fois le référentiel supprimé. Les problèmes faisant référence au référentiel source ne seront ni supprimés ni modifiés, mais les liens vers le référentiel source ajoutés aux problèmes échoueront une fois le référentiel supprimé. **Important** La suppression d'un dépôt source ne peut pas être annulée. Une fois que vous avez supprimé un dépôt source, vous ne pouvez plus le cloner, en extraire des données ou y transférer des données. La suppression d'un dépôt source ne supprime aucune copie locale de ce dépôt (dépôts locaux). Pour supprimer un dépôt local, utilisez le répertoire et les outils de gestion de fichiers de votre ordinateur local. **Note** Vous ne pouvez pas supprimer un référentiel lié dans la CodeCatalyst console. Pour supprimer un référentiel lié, cliquez sur le lien dans la liste des référentiels pour ouvrir ce référentiel dans le service qui l'héberge, puis supprimez-le. Pour plus d'informations, consultez la documentation du service qui héberge le référentiel lié. Pour supprimer un référentiel lié d'un projet, consultez[Dissociation GitHub des référentiels, des référentiels Bitbucket, des référentiels de projets et des GitLab projets Jira dans CodeCatalyst](extensions-unlink.md). **Pour supprimer un référentiel source** 1. Accédez au projet qui contient le référentiel source que vous souhaitez supprimer. 1. Sur la page de résumé de votre projet, choisissez le référentiel souhaité dans la liste, puis choisissez **Afficher le référentiel**. Dans le volet de navigation, vous pouvez également choisir **Code**, puis **Référentiels sources**. Choisissez le nom du référentiel dans la liste des référentiels sources du projet. 1. Sur la page d'accueil du référentiel, choisissez **Plus**, sélectionnez **Gérer les paramètres**, puis sélectionnez **Supprimer le référentiel**. 1. Passez en revue les informations relatives à la branche, à la pull request et au flux de travail associé pour vous assurer que vous ne supprimez pas un référentiel toujours utilisé ou dont le travail n'est pas terminé. Si vous souhaitez continuer, tapez **Supprimer**, puis choisissez **Supprimer**. # Organisation de votre code source : travaillez avec des branches sur Amazon CodeCatalyst Dans Git, les branches sont des pointeurs ou des références à un commit. Dans le développement, ils constituent un moyen pratique d'organiser votre travail. Vous pouvez utiliser des branches pour séparer le travail sur une version nouvelle ou différente des fichiers sans affecter le travail dans les autres branches. Vous pouvez utiliser des branches pour développer de nouvelles fonctionnalités, stocker une version spécifique de votre projet, etc. Vous pouvez configurer des règles pour les branches des référentiels sources afin de limiter certaines actions sur une branche à des rôles spécifiques dans ce projet. Les référentiels sources d'Amazon CodeCatalyst contiennent du contenu et une branche par défaut, quelle que soit la manière dont vous les créez. Les référentiels liés peuvent ne pas avoir de branche ou de contenu par défaut, mais ils ne sont pas utilisables CodeCatalyst tant que vous ne les avez pas initialisés et créé une branche par défaut. Lorsque vous créez un projet à l'aide d'un plan, vous CodeCatalyst créez un référentiel source pour ce projet qui inclut un fichier README.md, un exemple de code, des définitions de flux de travail et d'autres ressources. Lorsque vous créez un référentiel source sans utiliser de plan, un fichier README.md est ajouté pour vous en tant que premier commit, et une *branche par défaut* est créée pour vous. Cette branche par défaut est nommée *main*. Cette branche par défaut est celle utilisée comme branche de base ou par défaut dans les référentiels locaux (dépôts) lorsque les utilisateurs clonent le référentiel. **Note** Vous ne pouvez pas supprimer la branche par défaut. La première branche créée pour un dépôt source est la branche par défaut de ce dépôt. En outre, la recherche affiche uniquement les résultats de la branche par défaut. Vous ne pouvez pas rechercher de code dans d'autres branches. La création d'un dépôt dans crée CodeCatalyst également un premier commit, qui crée une *branche par défaut* contenant un fichier README.md. Le nom de cette branche par défaut est *main*. Il s'agit du nom de branche par défaut utilisé dans les exemples de ce guide. **Topics** + [Création d'une branche](source-create-delete-branch.md) + [Gestion de la branche par défaut d'un dépôt](source-branches-default-branch.md) + [Gérer les actions autorisées pour une branche à l'aide de règles de branche](source-branches-branch-rules.md) + [Commandes Git pour les branches](source-branches-git.md) + [Afficher les branches et les détails](source-branches-view.md) + [Supprimer une branche](source-branches-delete.md) # Création d'une branche Vous pouvez utiliser la CodeCatalyst console pour créer des branches dans un CodeCatalyst référentiel. Les branches que vous créez seront visibles par les autres utilisateurs la prochaine fois qu'ils extrairont des modifications du référentiel. **Astuce** Vous pouvez également créer des branches dans le cadre de la création d'un environnement de développement pour travailler sur votre code. Pour de plus amples informations, veuillez consulter [Création d’un environnement de développement](devenvironment-create.md). Vous pouvez également utiliser Git pour créer des branches. Pour de plus amples informations, veuillez consulter [Commandes Git communes pour les branches](source-branches-git.md#source-branches-git-table). **Pour créer une branche (console)** 1. Dans la CodeCatalyst console, accédez au projet dans lequel se trouve votre référentiel source. 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**. 1. Choisissez le référentiel dans lequel vous souhaitez créer une branche. 1. Sur la page d'aperçu du référentiel, choisissez **Plus**, puis sélectionnez **Créer une branche**. 1. Entrez le nom de la branche. 1. Choisissez une branche à partir de laquelle créer la branche, puis choisissez **Create**. # Gestion de la branche par défaut d'un dépôt Vous pouvez spécifier la branche à utiliser comme *branche par défaut* dans un référentiel source sur Amazon CodeCatalyst. Tous les référentiels sources CodeCatalyst contiennent du contenu et une branche par défaut, quelle que soit la manière dont vous les créez. Si vous utilisez un plan pour créer un projet, la branche par défaut du référentiel source créé pour ce projet est nommée *main*. Le contenu de la branche par défaut s'affiche automatiquement sur la page d'aperçu de ce référentiel. **Important** CodeCatalyst ne prend pas en charge la détection des modifications dans la branche par défaut pour les référentiels liés. Pour modifier la branche par défaut d'un dépôt lié, vous devez d'abord en dissocier CodeCatalyst, modifier la branche par défaut, puis la lier à nouveau. Pour de plus amples informations, veuillez consulter [Lier GitHub les référentiels, les référentiels Bitbucket, les référentiels de GitLab projets et les projets Jira dans CodeCatalyst](extensions-link.md). Il est recommandé de toujours s'assurer que vous disposez de la dernière version de l'extension avant de lier un dépôt. La branche par défaut est traitée un peu différemment de toutes les autres branches d'un dépôt source. Il possède une étiquette spéciale à côté de son nom, **Default**. La branche par défaut est celle utilisée comme branche de base ou par défaut dans les référentiels locaux (dépôts) lorsque les utilisateurs clonent le référentiel sur des ordinateurs locaux avec un client Git. Il s'agit également de la valeur par défaut utilisée lors de la création de flux de travail pour le stockage des fichiers YAML des flux de travail et pour le stockage des informations relatives aux problèmes. Lorsque vous utilisez la fonction de recherche dans CodeCatalyst, seule la branche par défaut d'un dépôt est recherchée. La branche par défaut étant fondamentale pour de nombreux aspects des projets, vous ne pouvez pas supprimer une branche si elle est spécifiée comme branche par défaut. Toutefois, vous pouvez choisir d'utiliser une autre branche comme branche par défaut. Dans ce cas, toutes [les règles de branche](source-branches-branch-rules.md) appliquées à l'ancienne branche par défaut seront automatiquement appliquées à la branche que vous spécifiez comme branche par défaut. **Note** Vous devez avoir le rôle d'administrateur de projet pour modifier la branche par défaut des référentiels sources dans les CodeCatalyst projets. Cela ne s'applique pas aux référentiels liés. **Pour afficher et modifier la branche par défaut d'un référentiel** 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 afficher les paramètres, y compris la branche par défaut. 1. Sur la page d'aperçu du référentiel, choisissez **Plus**, puis sélectionnez **Gérer les paramètres**. 1. Dans **Branche par défaut**, le nom de la branche spécifiée comme branche par défaut est affiché avec une étiquette intitulée **Default** à côté du nom. Cette même étiquette apparaît à côté du nom de la branche dans la liste des **branches dans Branches**. 1. Pour modifier la branche par défaut, choisissez **Modifier**. **Note** Vous devez avoir le rôle d'administrateur de projet dans le projet pour modifier la branche par défaut. 1. Choisissez le nom de la branche que vous souhaitez définir comme branche par défaut dans la liste déroulante, puis choisissez **Enregistrer**. # Gérer les actions autorisées pour une branche à l'aide de règles de branche Lorsque vous créez une branche, certaines actions sont autorisées pour cette branche en fonction des autorisations associées à ce rôle. Vous pouvez modifier les actions autorisées pour une branche spécifique en configurant les règles de branche. Les règles de branche sont basées sur le rôle de l'utilisateur dans votre projet. Vous pouvez choisir de limiter certaines actions prédéfinies, telles que le transfert de validations vers une branche, aux utilisateurs ayant un rôle particulier dans un projet. Cela peut vous aider à protéger des branches spécifiques d'un projet en limitant les rôles autorisés à effectuer certaines actions. Par exemple, si vous configurez une règle de branche pour autoriser uniquement les utilisateurs ayant le rôle d'**administrateur de projet** à fusionner ou à transférer vers cette branche, les utilisateurs ayant d'autres rôles dans le projet ne pourront pas modifier le code de cette branche. Vous devez examiner attentivement toutes les implications de la création d'une règle pour une branche. Par exemple, si vous choisissez de limiter les push vers une branche aux utilisateurs ayant le rôle d'**administrateur de projet**, les utilisateurs ayant le rôle de **contributeur** ne pourront pas créer ou modifier des flux de travail dans cette branche, car le flux de travail YAML est stocké dans cette branche, et ces utilisateurs ne peuvent pas valider et transmettre des modifications au YAML. Il est recommandé de tester les règles de branche une fois que vous les avez créées afin de vous assurer qu'elles n'ont aucun impact que vous n'avez pas prévu. Vous pouvez également utiliser les règles de branche conjointement avec les règles d'approbation pour les pull requests. Pour de plus amples informations, veuillez consulter [Gestion des exigences relatives à la fusion d'une pull request avec les règles d'approbation](source-pull-requests-approval-rules.md). **Note** Vous devez avoir le rôle d'administrateur de projet pour gérer les règles de branche pour les référentiels sources dans les CodeCatalyst projets. Vous ne pouvez pas créer de règles de branche pour les référentiels liés. Vous ne pouvez créer que des règles de branche plus restrictives que les autorisations par défaut pour le rôle. Vous ne pouvez pas créer de règles de branche plus permissives que ne le permet le rôle d'un utilisateur dans le projet. Par exemple, vous ne pouvez pas créer de règle de branche qui autorise les utilisateurs dotés du rôle de réviseur à accéder à la branche. Les règles de branche appliquées à la branche par défaut de votre dépôt source se comporteront légèrement différemment des règles de branche 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 les règles qui lui sont appliquées, sauf qu'elle ne sera plus protégée contre la suppression. Cette protection ne s'applique qu'à la branche par défaut actuelle. Les règles de branche ont deux états, **Standard** et **Personnalisé**. **Standard** indique que les actions autorisées sur une branche sont celles qui correspondent aux autorisations associées au rôle que l'utilisateur a CodeCatalyst pour les actions de branche. Pour en savoir plus sur les rôles dotés de quelles autorisations, consultez[Octroi d'accès avec des rôles d'utilisateur](ipa-roles.md). **Personnalisé** indique qu'une ou plusieurs actions de branche comportent des actions associées à une liste spécifique de rôles autorisés à effectuer cette action, différente des autorisations par défaut accordées par le rôle d'un utilisateur dans le projet. **Note** Si vous créez une règle de branche pour restreindre une ou plusieurs actions pour une branche, l'action **Supprimer la branche** est automatiquement définie pour autoriser uniquement les utilisateurs ayant le rôle d'administrateur de projet à supprimer cette branche. Le tableau suivant répertorie les actions et les paramètres par défaut des rôles autorisés à effectuer ces actions sur une branche. **Actions et rôles des succursales** | **Action sur les branches** | Rôles autorisés à effectuer cette action lorsqu'aucune règle de branche n'est appliquée | | --- | --- | | Fusionner avec la branche (cela inclut la fusion d'une pull request avec la branche) | Administrateur de projet, contributeur | | Appuyez sur la branche | Administrateur de projet, contributeur | | Supprimer la branche | Administrateur de projet, contributeur | | Supprimer la branche (branche par défaut) | Non autorisée | Vous ne pouvez pas supprimer les règles de branche, mais vous pouvez les mettre à jour pour autoriser les actions de tous les rôles qui seraient autorisés à effectuer cette action sur une branche, ce qui supprime effectivement la règle. **Note** Vous devez avoir le rôle d'administrateur de projet pour configurer les règles de branche pour les référentiels sources dans les CodeCatalyst projets. Cela ne s'applique pas aux référentiels liés. Les référentiels liés ne prennent pas en charge les règles de branche dans CodeCatalyst. **Pour afficher et modifier les règles de branche d'un référentiel** 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 de branche. 1. Sur la page d'aperçu du référentiel, choisissez **Branches**. 1. Dans la colonne **Règles de branche**, consultez l'état des règles pour chaque branche du référentiel. **Standard** indique que les règles d'action des branches sont les règles par défaut pour toutes les branches créées dans un référentiel source et qu'elles correspondent aux autorisations accordées à ces rôles dans un projet. **Personnalisé** indique qu'une ou plusieurs actions de branche sont soumises à des règles qui limitent une ou plusieurs actions autorisées pour cette branche à un ensemble de rôles différent. Pour consulter les détails des règles de branche d'une branche, choisissez le mot **Standard** ou **Personnalisé** à côté de la branche que vous souhaitez consulter. 1. Pour créer ou modifier une règle de branche, choisissez **Gérer les paramètres**. Sur la page des paramètres du référentiel source, dans **Règles de branche**, choisissez **Modifier**. 1. Dans **Branche**, choisissez le nom de la branche pour laquelle vous souhaitez configurer une règle dans la liste déroulante. Pour chacun des types d'action autorisés, choisissez les rôles que vous souhaitez autoriser à effectuer cette action dans la liste déroulante, puis choisissez **Enregistrer**. # Commandes Git pour les branches Vous pouvez utiliser Git pour créer, gérer et supprimer des branches dans le clone du dépôt source que vous avez sur votre ordinateur (votre dépôt local) ou dans vos environnements de développement, puis valider et transférer vos modifications dans votre dépôt CodeCatalyst source (le dépôt distant). Par exemple : **Commandes Git communes pour les branches** | | | | --- |--- | | Répertorie toutes les branches du dépôt local avec un astérisque (`*`) affiché à côté de votre branche actuelle. | `git branch` | | Extrait les informations relatives à toutes les branches existantes du référentiel distant vers le dépôt local. | `git fetch` | | Répertorie toutes les branches du dépôt local et les branches de suivi à distance du dépôt local. | `git branch -a` | | Répertorie uniquement les branches de suivi à distance dans le dépôt local. | `git branch -r` | | Crée une branche dans le dépôt local en utilisant le nom de branche spécifié. Cette branche n'apparaîtra pas dans le référentiel distant tant que vous n'aurez pas validé et appliqué la modification. | `git branch branch-name` | | Crée une branche dans le dépôt local en utilisant le nom de branche spécifié, puis y passe. | `git checkout -b branch-name` | | Passe à une autre branche du dépôt local en utilisant le nom de branche spécifié. | `git checkout other-branch-name` | | Transfère une branche du dépôt local vers le dépôt distant en utilisant le surnom spécifié par le dépôt local pour le dépôt distant et le nom de branche spécifié. Configure également les informations de suivi en amont pour la branche dans le dépôt local. | `git push -u remote-name branch-name` | | Fusionne les modifications d'une autre branche du dépôt local vers la branche actuelle du dépôt local. | `git merge from-other-branch-name` | | Supprime une branche du dépôt local sauf si elle contient du travail qui n'a pas été fusionné. | `git branch -d branch-name` | | Supprime une branche du référentiel distant en utilisant le surnom spécifié par le dépôt local pour le référentiel distant et le nom de branche spécifié. (Notez l'utilisation du signe deux points (`:`).) Vous pouvez également `--delete` le spécifier dans le cadre de la commande. | `git push remote-name :branch-name` `git push remote-name --delete branch-name` | Pour plus d'informations, consultez votre documentation Git. # Afficher les branches et les détails Vous pouvez consulter des informations sur les succursales distantes d'Amazon CodeCatalyst, notamment les détails des fichiers, des dossiers et le dernier commit pour une branche spécifique, dans la CodeCatalyst console Amazon. Vous pouvez également utiliser les commandes Git et votre système d'exploitation local pour afficher ces informations pour les branches distantes et locales. **Pour afficher les branches (console)** 1. Dans la CodeCatalyst console, accédez au projet qui contient le référentiel source dans lequel vous souhaitez afficher les branches. Choisissez **Code**, choisissez **Référentiels sources**, puis choisissez le référentiel source. 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 afficher une branche. 1. La branche par défaut du référentiel s'affiche. Vous pouvez consulter la liste des fichiers et des dossiers de la branche, des informations sur le dernier commit et le contenu du fichier README.md, s'il existe dans la branche. Pour afficher les informations relatives à une autre branche, sélectionnez-la dans la liste déroulante des branches du référentiel. 1. Pour afficher toutes les branches d'un référentiel, choisissez **Afficher tout**. La page Branches affiche des informations sur le nom, le dernier commit et les règles de chaque branche. Pour plus d'informations sur l'utilisation de Git et de votre système d'exploitation pour afficher les branches et les détails, consultez [Commandes Git communes pour les branches](source-branches-git.md#source-branches-git-table), votre documentation Git et la documentation de votre système d'exploitation. # Supprimer une branche Si vous n'avez plus besoin d'une branche, vous pouvez la supprimer. Par exemple, si vous avez fusionné une branche avec une modification de fonctionnalité dans la branche par défaut et que cette fonctionnalité a été publiée, vous souhaiterez peut-être supprimer la branche d'entité d'origine, car les modifications font déjà partie de la branche par défaut. Le fait de limiter le nombre de branches peut aider les utilisateurs à trouver la branche contenant les modifications sur lesquelles ils souhaitent travailler. Lorsque vous supprimez une branche, des copies de cette branche restent dans les clones du référentiel sur les ordinateurs locaux jusqu'à ce que les utilisateurs extraient et synchronisent ces modifications. **Pour supprimer une branche (console)** 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 supprimer une branche. 1. Sur la page d'aperçu du référentiel, choisissez le sélecteur déroulant à côté du nom de la branche, puis choisissez **Afficher tout**. 1. Choisissez la branche que vous souhaitez supprimer, puis choisissez **Supprimer la branche**. **Note** Vous ne pouvez pas supprimer la branche par défaut d'un référentiel. 1. Une boîte de dialogue de confirmation s'affiche. Il indique le référentiel, le nombre de pull requests ouvertes et le nombre de flux de travail associés à la branche. 1. Pour confirmer la suppression de la branche, tapez **supprimer** dans la zone de texte, puis choisissez **Supprimer**. Vous pouvez également utiliser Git pour supprimer des branches. Pour de plus amples informations, veuillez consulter [Commandes Git communes pour les branches](source-branches-git.md#source-branches-git-table). # Gestion des fichiers de code source sur Amazon CodeCatalyst Sur Amazon CodeCatalyst, un fichier est une information autonome dont la version est contrôlée et qui est accessible à vous et aux autres utilisateurs du référentiel source et de la succursale où le fichier est stocké. Vous pouvez organiser les fichiers de votre référentiel à l'aide d'une structure de répertoires. CodeCatalystsuit automatiquement toutes les modifications apportées à un fichier. Vous pouvez stocker différentes versions d'un fichier dans différentes branches du référentiel. Pour ajouter ou modifier plusieurs fichiers dans un référentiel source, vous pouvez utiliser un client Git, un environnement de développement ou un environnement de développement intégré (IDE). Pour ajouter ou modifier un seul fichier, vous pouvez utiliser la CodeCatalyst console. **Topics** + [Création ou ajout d'un fichier](source-files-create.md) + [Affichage d'un fichier](source-files-view.md) + [Afficher l'historique des modifications apportées à un fichier](source-files-view-history.md) + [Modification d'un fichier](source-files-edit.md) + [Modification du nom ou suppression d'un fichier](source-files-delete.md) # Création ou ajout d'un fichier Pour créer et ajouter des fichiers à un référentiel source, vous pouvez utiliser la CodeCatalyst console Amazon, un environnement de développement intégré (IDE) connecté ou un client Git. La CodeCatalyst console inclut un éditeur de code pour créer des fichiers. Cet éditeur est un moyen pratique de créer ou de modifier un fichier simple, tel qu'un fichier README.md, dans une branche d'un référentiel. Lorsque vous travaillez sur plusieurs fichiers, pensez à [créer un environnement de développement](devenvironment-create.md). **Pour créer un environnement de développement à partir d'un référentiel source** 1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Dans le volet de navigation, choisissez **Code**, puis sélectionnez **Référentiels sources**. 1. Choisissez le référentiel source dans lequel vous souhaitez travailler sur le code. 1. Choisissez **Create Dev Environment**. 1. Choisissez un IDE compatible dans le menu déroulant. Pour plus d’informations, consultez [Environnements de développement intégrés pris en charge pour les environnements de développement](devenvironment-create.md#devenvironment-supported-ide). 1. Effectuez l’une des actions suivantes : + Choisissez **Travailler dans une branche existante**, puis choisissez une branche dans le menu déroulant **Branche existante**. + Choisissez **Travailler dans une nouvelle branche**, entrez un nom de branche dans le champ **Nom** de la branche et choisissez une branche à partir de laquelle créer la nouvelle branche dans le menu déroulant **Créer une branche depuis**. 1. Ajoutez éventuellement un nom pour l'environnement de développement ou modifiez sa configuration. 1. Choisissez **Créer**. **Pour créer un fichier dans la CodeCatalyst console** 1. Accédez au projet dans lequel vous souhaitez créer un fichier. Pour plus d'informations sur la manière d'accéder à un référentiel, consultez[Affichage d’un référentiel source](source-repositories-view.md). 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 créer le fichier. 1. (Facultatif) Choisissez la branche dans laquelle vous souhaitez créer le fichier, si vous souhaitez créer le fichier dans une branche différente de la branche par défaut. 1. Choisissez **Créer un fichier**. 1. Entrez le nom du fichier dans **Nom du fichier**. Ajoutez le contenu du fichier dans l'éditeur. **Astuce** Si vous souhaitez créer le fichier dans un sous-dossier ou un sous-répertoire à la racine de la branche, incluez cette structure dans le nom du fichier. Lorsque vous êtes satisfait de vos modifications, choisissez **Commit**. 1. Dans **Nom du fichier**, vérifiez le nom du fichier et apportez-y les modifications souhaitées. Choisissez éventuellement la branche dans laquelle vous souhaitez créer le fichier dans la liste des branches disponibles dans **Branch**. Dans le **message de validation**, entrez éventuellement une description brève mais informative de la raison pour laquelle vous avez effectué cette modification. Cela sera affiché sous forme d'informations de validation de base pour le commit qui ajoute le fichier au référentiel source. 1. Choisissez **Commit** pour valider et transférer le fichier vers le référentiel source. Vous pouvez également ajouter des fichiers à un référentiel source en le clonant sur votre ordinateur local et en utilisant un client Git ou un environnement de développement intégré (IDE) connecté pour transférer vos fichiers et modifications. **Note** Si vous souhaitez ajouter un sous-module Git, vous devez utiliser un client Git ou un environnement de développement et exécuter la **git submodule add** commande. Vous ne pouvez pas ajouter ou afficher des sous-modules Git dans la CodeCatalyst console, ni visualiser les différences entre les sous-modules Git dans les pull requests. Pour plus d'informations sur les sous-modules Git, consultez la [documentation Git](https://git-scm.com/book/en/v2/Git-Tools-Submodules). **Pour ajouter un fichier à l'aide d'un client Git ou d'un environnement de développement intégré (IDE) connecté** 1. Clonez votre dépôt source sur votre ordinateur local. Pour de plus amples informations, veuillez consulter [Clonage d’un référentiel source](source-repositories-clone.md). 1. Créez des fichiers dans votre dépôt local ou copiez-les dans votre dépôt local. 1. Créez et envoyez un commit en effectuant l'une des opérations suivantes : + Si vous utilisez un client Git, sur le terminal ou sur la ligne de commande, exécutez la **git add** commande en spécifiant les noms des fichiers que vous souhaitez ajouter. Sinon, pour ajouter tous les fichiers ajoutés ou modifiés, exécutez la **git add** commande suivie d'un point simple ou double pour indiquer si vous souhaitez inclure toutes les modifications au niveau du répertoire actuel (point unique) ou toutes les modifications dans le répertoire actuel et tous les sous-répertoires (point double). Pour valider les modifications, exécutez la **git commit -m** commande et fournissez un message de validation. Pour transférer vos modifications dans le référentiel source CodeCatalyst, exécutez**git push**. Pour plus d'informations sur les commandes Git, consultez votre documentation Git et[Commandes Git pour les branches](source-branches-git.md). + Si vous utilisez un environnement de développement ou un IDE, créez des fichiers et ajoutez-y des fichiers, puis validez et appliquez vos modifications. Pour plus d'informations, consultez [Écrivez et modifiez du code avec les environnements de développement dans CodeCatalystÉcrire et modifier du code avec les environnements de développement](devenvironment.md) ou consultez la documentation de votre IDE. # Affichage d'un fichier Vous pouvez consulter les fichiers de votre référentiel source dans la CodeCatalyst console Amazon. Vous pouvez consulter les fichiers dans la branche par défaut et dans toutes les autres branches. Le contenu du fichier peut varier en fonction de la branche que vous choisissez d'afficher. **Pour afficher des fichiers dans la CodeCatalyst console** 1. Accédez au projet dans lequel vous souhaitez afficher les fichiers. Pour de plus amples informations, veuillez consulter [Affichage d’un référentiel source](source-repositories-view.md). 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 afficher les fichiers. 1. Une liste de fichiers et de dossiers s'affiche pour la branche par défaut. Les fichiers sont indiqués par une icône en forme de papier, tandis que les dossiers sont indiqués par une icône de dossier. 1. Effectuez l’une des actions suivantes : + Pour afficher les fichiers et les dossiers d'une autre branche, sélectionnez-la dans la liste des branches. + Pour développer un dossier, sélectionnez-le dans la liste. 1. Pour afficher le contenu d'un fichier spécifique, sélectionnez-le dans la liste. Le contenu du fichier sera affiché dans la branche. Pour afficher le contenu du fichier dans une autre branche, choisissez la branche souhaitée dans le sélecteur de branche. **Astuce** Lorsque vous consultez le contenu d'un fichier, vous pouvez sélectionner des fichiers supplémentaires à afficher dans **Afficher les fichiers**. Pour modifier un fichier, choisissez **Modifier**. Vous pouvez afficher plusieurs fichiers dans la console. Vous pouvez également afficher les fichiers que vous avez clonés sur votre ordinateur local à l'aide d'un client Git ou d'un environnement de développement intégré (IDE). Pour plus d'informations, consultez la documentation de votre client Git ou de votre IDE. **Note** Vous ne pouvez pas afficher les sous-modules Git dans la CodeCatalyst console. Pour plus d'informations sur les sous-modules Git, consultez la [documentation Git](https://git-scm.com/book/en/v2/Git-Tools-Submodules). # Afficher l'historique des modifications apportées à un fichier Vous pouvez consulter l'historique des modifications apportées à un fichier dans votre référentiel source dans la CodeCatalyst console Amazon. Cela peut vous aider à comprendre les modifications apportées au fichier par les différents validations effectuées sur la branche où vous choisissez de consulter l'historique du fichier. Par exemple, si vous consultez l'historique des modifications apportées au **readme.md** fichier dans la **main** branche du référentiel source, vous verrez une liste des validations incluant les modifications apportées à ce fichier dans cette branche. **Note** Vous ne pouvez pas consulter l'historique d'un fichier dans un référentiel lié dans la CodeCatalyst console. # Pour consulter l'historique d'un fichier dans la CodeCatalyst console 1. Accédez au projet dans lequel vous souhaitez consulter l'historique d'un fichier. Pour de plus amples informations, veuillez consulter [Affichage d’un référentiel source](source-repositories-view.md). 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**. 1. Choisissez le référentiel dans lequel vous souhaitez consulter l'historique d'un fichier. Choisissez la branche dans laquelle vous souhaitez afficher l'historique du fichier, puis sélectionnez le fichier dans la liste. Choisissez **Afficher l’historique**. 1. Consultez la liste des validations qui ont inclus des modifications apportées à ce fichier dans la branche spécifiée. Pour afficher le détail des modifications incluses dans un commit particulier, choisissez le message de validation correspondant à ce commit dans la liste. Les différences entre ce commit et son commit parent sont affichées. 1. Pour consulter l'historique des modifications apportées au fichier dans une autre branche, utilisez le sélecteur de branche pour modifier les vues de cette branche, sélectionnez le fichier dans la liste des fichiers, puis choisissez **Afficher l'historique**. **Note** Vous ne pouvez pas consulter l'historique des modifications apportées aux sous-modules Git dans la CodeCatalyst console. Pour plus d'informations sur les sous-modules Git, consultez la [documentation Git](https://git-scm.com/book/en/v2/Git-Tools-Submodules). # Modification d'un fichier Vous pouvez modifier des fichiers individuels dans la CodeCatalyst console Amazon. Pour modifier plusieurs fichiers à la fois, créez un environnement de développement ou clonez le référentiel et apportez vos modifications à l'aide d'un client Git ou d'un environnement de développement intégré (IDE). Pour plus d’informations, consultez [Écrivez et modifiez du code avec les environnements de développement dans CodeCatalystÉcrire et modifier du code avec les environnements de développement](devenvironment.md) ou [Clonage d’un référentiel source](source-repositories-clone.md). **Pour modifier un fichier dans la CodeCatalyst console** 1. Accédez au projet dans lequel vous souhaitez modifier un fichier. Pour plus d'informations sur la manière d'accéder à un référentiel, consultez[Affichage d’un référentiel source](source-repositories-view.md). 1. Choisissez le référentiel dans lequel vous souhaitez modifier le fichier. Choisissez **Afficher les branches**, puis choisissez la branche dans laquelle vous souhaitez travailler. Choisissez le fichier dans la liste des fichiers et dossiers de cette branche. Le contenu du fichier s'affiche. 1. Choisissez **Modifier**. 1. Dans l'éditeur, modifiez le contenu du fichier, puis choisissez **Commit**. Facultativement, dans la **section Valider les modifications**, ajoutez des informations supplémentaires sur la modification dans le **message de validation**. Lorsque vous êtes satisfait de vos modifications, choisissez **Commit**. # Modification du nom ou suppression d'un fichier Vous pouvez renommer ou supprimer des fichiers dans un environnement de développement, localement sur votre ordinateur ou dans un environnement de développement intégré (IDE). Une fois que vous avez renommé ou supprimé les fichiers, validez et transférez ces modifications dans le référentiel source. Vous ne pouvez pas renommer ou supprimer des fichiers dans la CodeCatalyst console Amazon. # 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**. # Comprendre les modifications apportées au code source à l'aide de validations sur Amazon CodeCatalyst Les validations sont des instantanés du contenu et des modifications du contenu de votre référentiel. Chaque fois qu'un utilisateur valide et apporte une modification à une branche, ces informations sont enregistrées. Les informations de validation de Git incluent l'auteur de la validation, la personne qui a effectué la modification, la date et l'heure, ainsi que les modifications apportées. Des informations similaires sont automatiquement incluses lorsque vous créez ou modifiez un fichier dans la CodeCatalyst console Amazon, mais le nom de l'auteur est votre nom CodeCatalyst d'utilisateur. Vous pouvez également ajouter des balises Git aux validations pour vous aider à identifier des validations spécifiques. Sur Amazon CodeCatalyst, vous pouvez : + Afficher la liste des validations pour une branche. + Affichez les validations individuelles, y compris les modifications apportées à une validation par rapport à son ou ses parents. Vous pouvez également consulter des fichiers et des dossiers. Pour de plus amples informations, veuillez consulter [Gestion des fichiers de code source sur Amazon CodeCatalyst](source-files.md). **Topics** + [Afficher les validations d'une branche](#source-commits-view) + [Modifier le mode d'affichage des validations (CodeCatalyst console)](#source-commits-settings) ## Afficher les validations d'une branche Vous pouvez consulter l'historique des modifications apportées à une branche en consultant les validations de la branche dans la CodeCatalyst console. Cela vous permet de comprendre qui a apporté des modifications à la succursale et à quel moment. Vous pouvez également consulter les modifications apportées dans un commit spécifique. **Astuce** Vous pouvez également consulter l'historique des validations ayant apporté des modifications à un fichier spécifique. Pour de plus amples informations, veuillez consulter [Affichage d'un fichierAfficher l'historique des modifications apportées à un fichier](source-files-view-history.md). Vous pouvez également consulter les validations à l'aide de votre client Git. Pour plus d'informations, consultez votre documentation Git. **Pour afficher les validations (console)** 1. Accédez au projet qui contient le référentiel source dans lequel vous souhaitez afficher les validations. 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 afficher les validations d'une branche. 1. La branche par défaut du référentiel s'affiche, y compris les informations relatives au dernier commit effectué sur la branche. Choisissez **Commits**. Vous pouvez également choisir **Plus**, puis **Afficher les validations**. 1. Pour afficher les validations pour une autre branche, choisissez le sélecteur de branche, puis choisissez le nom de la branche. 1. Pour afficher les détails d'un commit en particulier, choisissez son titre dans **Titre du commit**. Les détails du commit sont affichés, y compris des informations sur son commit parent et les modifications apportées au code en comparant le commit parent au commit spécifié. **Astuce** Si un commit a plusieurs parents, vous pouvez choisir le commit parent dont vous souhaitez afficher les informations et afficher les modifications en cliquant sur l'icône déroulante à côté de l'ID de validation parent. ## Modifier le mode d'affichage des validations (CodeCatalyst console) Vous pouvez modifier les informations affichées dans la vue des **validations**. Vous pouvez choisir de masquer ou d'afficher des colonnes telles que l'auteur et l'ID de validation. **Pour modifier le mode d'affichage des validations (console)** 1. Accédez au projet qui contient le référentiel source dans lequel vous souhaitez afficher les validations. 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 modifier la façon dont vous visualisez les validations. 1. La branche par défaut du référentiel s'affiche, y compris les informations relatives au dernier commit effectué sur la branche. Choisissez **Commits**. 1. Choisissez l’icône d’engrenage. 1. Dans les **préférences**, choisissez le nombre de validations à afficher et indiquez si vous souhaitez afficher les informations relatives à l'auteur, à la date de validation et à l'ID de validation. **Note** Vous ne pouvez pas masquer le titre du commit dans l'affichage des informations. 1. Lorsque vous avez apporté vos modifications, choisissez **Enregistrer** pour les enregistrer ou **Annuler** pour les ignorer. # Quotas pour les référentiels sources dans CodeCatalyst Le tableau suivant décrit les quotas et les limites pour les référentiels sources sur Amazon CodeCatalyst. Pour plus d'informations sur les quotas sur Amazon CodeCatalyst, consultez[Quotas pour CodeCatalyst](quotas.md). | Ressource | Informations | | --- | --- | | Noms des branches | Toute combinaison de caractères autorisés comprise entre 1 et 256 caractères doit être unique au sein d'un référentiel. Les noms de branche ne peuvent pas : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codecatalyst/latest/userguide/source-quotas.html) Les noms de branche sont des références. Un grand nombre des restrictions qui s'appliquent aux noms de branche sont basées sur le standard de référence Git. Pour plus d'informations, consultez [Git Internals et [git-check-ref-format](https://git-scm.com/docs/git-check-ref-format).](https://git-scm.com/book/en/v2/Git-Internals-Git-References) | | Commentaires sur une pull request | Maximum de 1 000 sur une pull request. | | Valider le message | Maximum de 1024 caractères. | | Chemins de fichier | Toute combinaison de caractères autorisés pour une longueur de 1 à 4,096 caractères. Un chemin de fichier doit être un nom non ambigu qui spécifie le fichier et son emplacement exact. Un chemin de fichier ne peut pas avoir une profondeur de plus de 20 répertoires. En outre, un chemin de fichier ne peut pas :[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codecatalyst/latest/userguide/source-quotas.html) Les noms et les chemins de fichier doivent être complets. Le nom et le chemin d'un fichier sur votre ordinateur local doivent suivre les normes définies pour ce système d'exploitation. Lorsque vous spécifiez le chemin d'accès à un fichier dans un référentiel, utilisez les normes d'Amazon Linux. | | Taille de fichier | Maximum de 6 Mo pour chaque fichier individuel lors de l'utilisation de la CodeCatalyst console. | | Taille du fichier visible dans la console CodeCatalyst | Maximum de 6 Mo pour chaque fichier individuel lors de l'utilisation de la CodeCatalyst console. | | Taille d'objet blob git | Maximum de 2 Go. Aucune limite ne s'applique au nombre ou à la taille totale de tous les fichiers d'une même validation, dans la mesure où les métadonnées ne dépassent pas 6 Mo et où un objet blob unique ne dépasse pas 2 Go. Toutefois, la meilleure pratique consiste à envisager de faire plusieurs petits engagements plutôt qu'un seul grand commit. | | Métadonnées pour une validation | Maximum de 6 Mo pour les [métadonnées combinées d'un commit](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects) (par exemple, la combinaison des informations sur l'auteur, de la date, de la liste de validation parent et des messages de validation). Aucune limite ne s'applique au nombre ou à la taille totale de tous les fichiers d'une même validation, dans la mesure où les données ne dépassent pas 20 Mo, où un fichier individuel ne dépasse pas 6 Mo et où un objet blob unique ne dépasse pas 6 Go. | | Nombre de CodeCatalyst problèmes pouvant être liés à une pull request | 50 | | Nombre de problèmes liés à Jira pouvant être liés à une pull request | 50 | | Nombre de pull requests ouvertes dans un espace | Maximum de 1 000 pour un CodeCatalyst espace Amazon. | | Nombre total de pull requests dans un espace | Maximum de 10 000 pour un CodeCatalyst espace Amazon. | | Nombre de références dans une seule commande push | Maximum de 4 000, y compris pour créer, supprimer et mettre à jour. Le nombre total de références dans le référentiel n'est pas limité. | | Nombre de référentiels dans un espace | Maximum de 5 000 pour un CodeCatalyst espace Amazon. | | Descriptions de référentiel | Toute combinaison de caractères pour une longueur de 0 à 1 000 caractères. Les descriptions de référentiel sont facultatives. | | Noms de référentiel | Les noms des référentiels doivent être uniques au sein d'un projet. Ils peuvent contenir n'importe quelle combinaison de lettres, de chiffres, de points, de traits de soulignement et de tirets d'une longueur comprise entre 1 et 100 caractères. Les noms ne distinguent pas les majuscules et minuscules. Les noms de dépôt ne peuvent pas se terminer par .git, ne peuvent pas contenir d'espaces et ne peuvent contenir aucun des caractères suivants : `! ? @ # $ % ^ & * ( ) + = { } [ ] \| \ / > < ~ ` ' " ; : ` | | Taille du référentiel | La taille des référentiels dépend des limites de stockage globales de votre espace. Pour plus d’informations, veuillez consulter [Tarification d’](https://codecatalyst.aws/explore/pricing) et [Résolution des problèmes liés aux référentiels sources](troubleshooting-source.md). | | Réviseurs pour une pull request | Maximum de 100 réviseurs au total (facultatif ou obligatoire) pour une pull request. | | Résumés écrits pour les pull requests | Le nombre maximum de résumés écrits pour les pull requests dépend du niveau de facturation de votre espace. Pour plus d’informations, consultez [Tarification d’](https://codecatalyst.aws/explore/pricing). |