{"meta":{"title":"À propos des dépôts verrouillés","intro":"Les dépôts peuvent être verrouillés pour empêcher toute modification, souvent pour les migrations.","product":"Migrations","breadcrumbs":[{"href":"/fr/migrations","title":"Migrations"},{"href":"/fr/migrations/overview","title":"Vue d’ensemble"},{"href":"/fr/migrations/overview/about-locked-repositories","title":"Dépôts verrouillés"}],"documentType":"article"},"body":"# À propos des dépôts verrouillés\n\nLes dépôts peuvent être verrouillés pour empêcher toute modification, souvent pour les migrations.\n\n## À propos des dépôts verrouillés\n\nLorsque vous migrez des référentiels vers ou depuis des produits, vos référentiels d’origine et de GitHub destination peuvent être « verrouillés » pour la migration. Lorsqu'un dépôt est verrouillé, vous ne pouvez pas apporter de modifications au dépôt, comme pousser des commits, créer des issues ou commenter des pull requests.\n\nLe verrouillage de vos dépôts pendant la migration dépend des outils que vous utilisez et des options que vous choisissez lors de l’exécution de la migration. Lorsqu’un référentiel est verrouillé, une bannière avec le texte suivant s’affiche sur la page du référentiel sur GitHub:\n\n> Ce dépôt est en cours de migration. Il est verrouillé pendant que la migration est en cours.\n\nSouvent, les dépôts sont déverrouillés automatiquement une fois la migration terminée. Dans d’autres cas, le déverrouillage d’un dépôt est une étape manuelle et le processus requis pour déverrouiller un dépôt dépend de l’outil de migration que vous avez utilisé.\n\n## Dépôts verrouillés par GitHub Enterprise Importer\n\nPendant qu’une migration est en cours, l’accès au référentiel de destination est verrouillé par GitHub Enterprise Importer. Si la migration se termine correctement, le dépôt se déverrouille automatiquement. Toutefois, en cas de problème avec la migration, notamment un échec de migration, le dépôt peut rester verrouillé.\n\nGitHub Enterprise Importer ne verrouille pas les référentiels sources par défaut. Les référentiels sources ne seront verrouillés que si vous spécifiez l’option `--lock-source-repo` dans le GitHub CLIou l’attribut `lockSource` dans la `startRepositoryMigration` mutation GraphQL.\n\n> \\[!NOTE]\n> Nous vous déconseillons de verrouiller les dépôts sources, sauf si vous êtes sûr de ne pas vouloir les déverrouiller par la suite. Envisagez plutôt d’archiver les dépôts. Pour plus d’informations, consultez « [Archivage de référentiels](/fr/repositories/archiving-a-github-repository/archiving-repositories) ».\n\nPour plus d’informations sur le déverrouillage des référentiels verrouillés par GitHub Enterprise Importer, consultez [Résolution des problèmes liés à votre migration avec GitHub Enterprise Importer](/fr/migrations/troubleshooting/troubleshooting-your-migration-with-github-enterprise-importer#locked-repositories).\n\n## Référentiels archivés par Enterprise Live Migrations\n\nDans les versions les plus récentes, GitHub Enterprise Server archive le dépôt source, au lieu de le verrouiller. Cela permet de conserver le référentiel disponible pour les opérations de lecture.\n\nSi un basculement échoue une fois que le référentiel source a été archivé, le ELM service tentera de désarchiver le référentiel. En cas d’échec, un administrateur de référentiel peut annuler l’archivage du référentiel. Consultez « [Archivage de référentiels](/fr/repositories/archiving-a-github-repository/archiving-repositories#unarchiving-a-repository) ».\n\nN’oubliez pas que l’annulation de l’archivage d’un référentiel entraîne une charge supplémentaire sur l’instance, car tous les problèmes et demandes de tirage dans le référentiel seront réindexés dans Elasticsearch.\n\nUne fois le référentiel source désarchivé, vous pouvez soit réessayer le basculement à l’aide de `elm migration cutover-to-destination --migration-id MIGRATION-ID`, soit abandonner la migration à l’aide de `elm migration cancel --migration-id MIGRATION-ID` et démarrer une nouvelle migration lorsque vous serez prêt.\n\n## Dépôts verrouillés par l’API REST « Migrations d’organisations »\n\nLorsque vous appelez le point de terminaison [Démarrer une migration d’organisation](/fr/rest/migrations/orgs#start-an-organization-migration) afin de générer une archive de migration pour un référentiel source, le référentiel n’est pas verrouillé par défaut. Le dépôt est verrouillé seulement si vous définissez le paramètre `lock_repositories` avec la valeur `true`.\n\nSi vous verrouillez un référentiel via ce point de terminaison, vous pouvez le déverrouiller à l’aide du point de terminaison [Déverrouiller un référentiel d’organisation](/fr/rest/migrations/orgs#unlock-an-organization-repository).\n\nSi le référentiel est stocké sur GitHub Enterprise Server, un administrateur de site peut également déverrouiller le référentiel à l’aide du tableau de bord administrateur du site. Pour plus d’informations, consultez [Verrouillage d’un dépôt](/fr/enterprise-server@3.22/admin/managing-accounts-and-repositories/managing-repositories-in-your-enterprise/locking-a-repository) dans la GitHub Enterprise Server documentation.\n\n## Dépôts verrouillés par `ghe-migrator`\n\nLorsque vous utilisez `ghe-migrator`, le référentiel de destination sur GitHub Enterprise Server est verrouillé par défaut et n'est pas automatiquement déverrouillé.\n\nSi l’importation réussit, vous pouvez déverrouiller le dépôt avec la commande `ghe-migrator unlock`. Pour plus d’informations, consultez « [Migration de données vers GitHub Enterprise Server](/fr/migrations/using-ghe-migrator/migrating-data-to-github-enterprise-server#unlocking-repositories-on-the-target-instance) ».\n\nSi l’importation échoue, vos données n’ont pas toutes été migrées. Nous vous recommandons de supprimer le dépôt et de réessayer la migration pour éviter de perdre des données.\n\nSi vous êtes sûr de vouloir utiliser le dépôt, un administrateur de site peut déverrouiller le dépôt à l’aide du tableau de bord de l’administrateur de site. Pour plus d’informations, consultez [Verrouillage d’un dépôt](/fr/enterprise-server@3.22/admin/managing-accounts-and-repositories/managing-repositories-in-your-enterprise/locking-a-repository) dans la GitHub Enterprise Server documentation.\n\nLe dépôt source n’est pas verrouillé par défaut, seulement si l’argument `--lock` est spécifié lors de la préparation du dépôt à l’exportation avec la commande `ghe-migrator add`. Pour déverrouiller le dépôt, utilisez la commande `ghe-migrator unlock`. Pour plus d’informations, consultez « [Migration de données vers GitHub Enterprise Server](/fr/migrations/using-ghe-migrator/migrating-data-to-github-enterprise-server#unlocking-repositories-on-the-source) ».\n\n## Dépôts verrouillés par la mutation GraphQL `startImport`\n\nLorsque vous utilisez la mutation GraphQL `startImport`, le dépôt de destination est verrouillé par défaut et n’est pas déverrouillé automatiquement.\n\nSi l’importation réussit, vous pouvez déverrouiller le dépôt avec la mutation GraphQL `unlockImportedRepositories`. Pour obtenir de la documentation, contactez votre représentant Services experts ou partenaire GitHub.\n\nSi l’importation échoue, vous ne pouvez pas déverrouiller le dépôt vous-même. Étant donné qu’une migration ayant échoué signifie que vos données n’ont pas toutes été migrées, nous vous recommandons de supprimer le dépôt et de réessayer la migration pour éviter de perdre des données.\n\nSi vous êtes sûr de vouloir déverrouiller le référentiel, contactez nous par le biais du portail ."}