# Migrer vos dépôts de GitLab vers GitHub
Effectuez une exécution d’évaluation, puis migrez vos dépôts de GitLab vers GitHub.
## Prerequisites
* Vous devez avoir terminé toutes les phases précédentes de ce guide.
* Le projet GitLab doit être activé pour les exportations. Consultez [Activer l’exportation de projet](https://docs.gitlab.com/administration/settings/import_and_export_settings/#enable-project-export) et [la configuration Sidekiq pour les importations](https://docs.gitlab.com/administration/sidekiq/configuration_for_imports/) dans la documentation GitLab.
* Assurez-vous que vous comprenez les données qui seront migrées et les limitations de prise en charge connues de l’importateur. Pour plus d’informations, consultez [Comprendre les migrations de GitLab vers GitHub](/fr/migrations/using-github-enterprise-importer/migrate-from-gitlab/understand-migrations).
* Bien que cela ne soit pas obligatoire, nous vous recommandons d’interrompre votre travail pendant votre migration de production. Importer ne prend pas en charge les migrations delta, donc aucune modification apportée pendant la migration ne sera migrée. Si vous choisissez de ne pas interrompre le travail pendant votre migration de production, vous devrez migrer manuellement ces modifications.
## Exécution d’une exécution d’évaluation
Pour vous aider à identifier les problèmes qui peuvent être propres à votre entreprise, nous vous recommandons vivement d’effectuer un essai de votre migration. Avec un essai, vous apprendrez :
* Indique si la migration d’un référentiel donné peut se terminer correctement.
* Indique si vous pouvez récupérer le référentiel migré vers un état utilisable.
* Combien de temps une migration prendra-t-elle pour s'exécuter.
Les exécutions d’essai peuvent se produire à tout moment et le travail n’a pas besoin d’arrêter pendant la migration. Pour réduire le temps nécessaire à l’exécution de vos migrations d’essai, vous pouvez planifier les lots de vos exécutions d’essai les unes à la suite des autres. Les utilisateurs de ces dépôts peuvent ensuite valider les résultats quand ils veulent.
1. Créez une organisation de test pour vos migrations d’essai.
Vous pouvez utiliser une seule organisation pour toutes les exécutions d’essai, ou vous pouvez créer une organisation de test pour chaque organisation de destination prévue. Pensez à inclure `-sandbox` à la fin des noms d’organisation pour clarifier que les organisations sont destinées uniquement à la validation de la migration et non à la production. Vous pouvez supprimer les organisations de test une fois que vous avez terminé.
2. Exécutez les migrations d’essai.
3. Vérifiez que vous êtes en mesure d’effectuer les tâches de suivi dans [Tâches de suivi](/fr/migrations/using-github-enterprise-importer/migrate-from-gitlab/follow-up-tasks).
4. Demandez aux utilisateurs de valider les résultats des migrations.
5. Résolvez les problèmes découverts par vos migrations d’essai.
6. Si vous le souhaitez, supprimez l’organisation de test.
## Migration d’un référentiel unique
Pour migrer un référentiel, utilisez la `gh gl2gh migrate-repo` commande.
```shell copy
gh gl2gh migrate-repo \
--gitlab-server-url GITLAB_SERVER_URL \
--gitlab-group SOURCE_GROUP \
--gitlab-project SOURCE_PROJECT \
--github-org DESTINATION \
--github-repo NEW_REPO_NAME \
--use-github-storage
```
Remplacez les espaces réservés dans la commande ci-dessus par les valeurs suivantes.
| Texte de remplacement | Valeur |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| GITLAB\_SERVER\_URL | URL complète de votre instance GitLab, telle que `https://gitlab.com` ou `https://gitlab.example.com`. |
| SOURCE\_GROUP | Chemin complet du groupe ou de l’espace de noms qui contient le projet. Pour les sous-groupes imbriqués, utilisez le chemin d’accès complet, par `parent-group/subgroup`exemple . |
| SOURCE\_PROJECT | Projet GitLab à migrer. |
| DESTINATION | L’organisation de destination sur GitHub. |
| NEW\_REPO\_NAME | Nom du référentiel sur GitHub. |
Si vous n’utilisez GitHub-owned blob storagepas, consultez [Configurer le stockage d’objets blob](/fr/migrations/using-github-enterprise-importer/migrate-from-gitlab/configure-storage).
### Arguments supplémentaires
| Argument | Description |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--target-repo-visibility` | Définit la visibilité du nouveau référentiel sur `public`, `private`ou `internal`. La valeur par défaut est `private`. |
| `--target-api-url TARGET-API-URL` | Si vous migrez vers GHE.com, ajoutez `--target-api-url TARGET-API-URL`, où TARGET-API-URL est l'URL de l'API de base pour le sous-domaine de votre entreprise. Par exemple : `https://api.octocorp.ghe.com`. |
| `--target-uploads-url TARGET-UPLOADS-URL` | Si vous migrez vers GHE.com et utilisez GitHub-owned blob storage, ajoutez `--target-uploads-url TARGET-UPLOADS-URL`également , où TARGET-UPLOADS-URL est l’URL de l’API de chargement de base pour le sous-domaine de votre entreprise. Par exemple : `https://uploads.octocorp.ghe.com`. La valeur par défaut est `https://uploads.github.com`. |
| `--no-ssl-verify` | Désactive la vérification SSL lorsque les GL2GH extension discussions avec votre instance GitLab sont désactivées. Utilisez cette option uniquement si votre instance GitLab utilise un certificat auto-signé. Toutes les autres étapes vérifient toujours SSL. |
| `--archive-url URL` | Importe une archive précédemment exportée à partir d’une URL, au lieu d’exporter à nouveau le projet à partir de GitLab. |
| `--archive-path PATH` | Importe une archive précédemment exportée à partir d’un chemin d’accès de fichier local, au lieu d’exporter à nouveau le projet à partir de GitLab. |
| `--keep-archive` | Conserve l’archive d’exportation localement au lieu de la supprimer après un chargement réussi. |
## Génération d’un script de migration
Si vous souhaitez migrer plusieurs référentiels à GitHub Enterprise Cloud la fois, utilisez-le GitHub CLI pour générer un script de migration. Le script résultant contient une `migrate-repo` commande par dépôt.
Pour générer un script de migration, exécutez la commande `gh gl2gh generate-script`.
```shell copy
gh gl2gh generate-script \
--gitlab-server-url GITLAB_SERVER_URL \
--github-org DESTINATION \
--output FILENAME \
--use-github-storage
```
Remplacez les espaces réservés dans la commande ci-dessus par les valeurs suivantes.
| Texte de remplacement | Valeur |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| GITLAB\_SERVER\_URL | URL complète de votre instance GitLab, telle que `https://gitlab.com` ou `https://gitlab.example.com`. |
| DESTINATION | L’organisation de destination sur GitHub. |
| FILENAME | Nom de fichier du script de migration résultant
Si vous utilisez le Terminal, choisissez une extension de fichier `.ps1`, car le script généré exige l’exécution de PowerShell. Vous pouvez installer PowerShell pour [Mac](https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-macos?view=powershell-7.2) ou [Linux](https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-linux?view=powershell-7.2). |
Par défaut, le script inclut chaque projet que le jeton peut accéder. Pour étendre le script, ajoutez `--gitlab-group GROUP`ou `--gitlab-group GROUP --gitlab-project PROJECT` pour un seul projet.
Si vous n’utilisez GitHub-owned blob storagepas, consultez [Configurer le stockage d’objets blob](/fr/migrations/using-github-enterprise-importer/migrate-from-gitlab/configure-storage).
### Arguments supplémentaires
| Argument | Description |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--target-api-url TARGET-API-URL` | Si vous migrez vers GHE.com, ajoutez `--target-api-url TARGET-API-URL`, où TARGET-API-URL est l'URL de l'API de base pour le sous-domaine de votre entreprise. Par exemple : `https://api.octocorp.ghe.com`. |
| `--target-uploads-url TARGET-UPLOADS-URL` | Si vous migrez vers GHE.com et utilisez GitHub-owned blob storage, ajoutez `--target-uploads-url TARGET-UPLOADS-URL`également , où TARGET-UPLOADS-URL est l’URL de l’API de chargement de base pour le sous-domaine de votre entreprise. Par exemple : `https://uploads.octocorp.ghe.com`. La valeur par défaut est `https://uploads.github.com`. |
### Examen du script de migration
Après avoir généré le script, passez en revue le fichier et, éventuellement, modifiez le script.
* S’il y a des dépôts que vous ne souhaitez pas migrer, supprimez ou commentez les lignes correspondantes.
* Si vous souhaitez que les dépôts aient un nom différent dans l’organisation de destination, mettez à jour la valeur de l’indicateur `--github-repo` correspondant.
* Si vous souhaitez modifier la visibilité d’un nouveau référentiel, ajoutez ou mettez à jour l’indicateur correspondant `--target-repo-visibility` .
### Migrer des dépôts
Si l'exécution de votre essai a été réussie et que vous avez pu effectuer les tâches de suivi, vous pouvez passer à la migration réelle.
> \[!WARNING] Nous vous recommandons de suspendre vos activités dans les référentiels que vous migrez. Toutes les modifications apportées pendant ou après la migration doivent être migrées manuellement.
Exécutez le script que vous avez généré. Remplacez FILENAME dans les commandes ci-dessous par le nom de fichier que vous avez fourni lors de la génération du script.
* Si vous employez le Terminal, utilisez `./`.
```shell copy
./FILENAME
```
* Si vous employez PowerShell, utilisez `.\`.
```shell copy
.\FILENAME
```