Skip to main content

À propos de ghe-migrator

Vous pouvez utiliser ghe-migrator pour transférer des données d’un emplacement source (organisation GitHub.com ou instance GitHub Enterprise Server) vers une instance cible GitHub Enterprise Server.

Types de migrations

Vous pouvez effectuer trois types de migrations :

  • Une migration d’une instance de GitHub Enterprise Server vers une autre instance GitHub Enterprise Server existante. Vous pouvez migrer n’importe quel nombre de dépôts appartenant à un utilisateur ou une organisation sur l’instance. Avant d’effectuer une migration, vous devez disposer d’un accès administrateur de site aux deux instances.
  • Une migration d’une organisation GitHub.com vers une instance de GitHub Enterprise Server. Vous pouvez migrer n’importe quel nombre de dépôts appartenant à l’organisation. Avant d’effectuer une migration, vous devez disposer d’un accès administratif à l’organisation GitHub.com et d’un accès administrateur de site à l’instance cible.
  • Les essais sont des migrations qui importent des données dans une instance de préproduction. Ils vous permettent de voir ce qui se passerait si une migration était appliquée à GitHub.com. Nous vous recommandons vivement d’effectuer un essai sur une instance intermédiaire avant d’importer des données dans votre instance de préproduction.

Remarque : l’utilisation de ghe-migrator n’est pas recommandée pour transférer une instance GitHub Enterprise Server d’un hyperviseur à un autre. Nous vous suggérons plutôt de sauvegarder et de restaurer dans le nouvel emplacement avec GitHub Enterprise Server Backup Utilities, ou de créer un réplica dans le nouvel emplacement, puis de basculer vers l’appliance réplica. Pour plus d’informations, consultez « Configuration des sauvegardes sur votre instance », « Création d’un réplica à haute disponibilité » et « Lancement d’un basculement vers votre appliance réplica ».

Données migrées

ghe-migrator est centré sur un référentiel. La plupart des données associées à un dépôt peuvent être migrées. Par exemple, un dépôt dans une organisation migre le dépôt et l’organisation ainsi que tous les utilisateurs, équipes, problèmes et demandes de tirage (pull request) associés au dépôt.

Les éléments du tableau ci-dessous peuvent être migrés avec un dépôt. Les éléments qui ne figurent pas dans la liste des données migrées ne peuvent pas être migrés, notamment les ressources Git LFS.

Remarque : les relations de duplication ne persistent pas après une migration.

Données associées à un dépôt migréNotes
UtilisateursLes @mentions d’utilisateurs sont réécrites pour correspondre à la cible.
OrganisationsLe nom et les détails d’une organisation sont migrés.
RéférentielsLes liens vers les arborescences, blobs, commits et lignes Git sont réécrits pour correspondre à la cible. Les référentiels internes sont migrés en tant que dépôts privés. L’état de l’archive n’est pas défini.
WikisToutes les données wiki sont migrées.
TeamsLes @mentions d’équipes sont réécrites pour correspondre à la cible.
Étapes majeuresLes horodatages sont conservés.
Panneaux Projects (classic)Projets (classique) associés au dépôt et à l'organisation qui possède le dépôt sont migrés. Projects, la toute nouvelle expérience de projet, n'est pas pris en charge.
ProblèmesLes références de problème et les horodatages sont conservés.
Commentaires de problèmeLes références croisées aux commentaires sont réécrites pour l’instance cible.
Demandes de tirageLes références croisées aux demandes de tirage sont réécrites pour correspondre à la cible. Les horodatages sont conservés.
Revues de demande de tirageLes revues de demande de tirage et les données associées sont migrées.
Commentaires de revues de demande de tirageLes références croisées aux commentaires sont réécrites pour l’instance cible. Les horodatages sont conservés. Les commentaires au niveau du fichier ne sont pas migrés.
Commentaires de commitLes références croisées aux commentaires sont réécrites pour l’instance cible. Les horodatages sont conservés.
VersionsToutes les données de versions sont migrées.
Actions effectuées sur les demandes de tirage ou les problèmesToutes les modifications apportées aux demandes de tirage ou aux problèmes, notamment l’attribution d’utilisateurs, le renommage des titres et la modification d’étiquettes, sont conservées ainsi que les horodatages pour chaque action.
Pièces jointesLes fichiers joints aux problèmes et demandes de tirage sont migrés. Vous pouvez désactiver la migration de ces éléments.
WebhooksSeuls les webhooks actifs sont migrés.
Clés de déploiement de dépôtLes clés de déploiement de dépôt sont migrées.
Branches protégéesLes paramètres de branche protégée et les données associées sont migrés.

À propos de la migration des données d’authentification externes

Si l’emplacement source de votre migration est un produit GitHub qui utilise l’authentification LDAP ou SAML, ghe-migrator ne migre pas les données d’authentification externe liées aux comptes d’utilisateur. Pour plus d’informations sur les options d’authentification, consultez GitHub Enterprise Server, et consultez « À propos de l’authentification pour votre entreprise » dans les documents GitHub Enterprise Server » ou les documents GitHub Enterprise Cloud.

S vous migrez vers une instance de destination, puis configurez l’authentification externe, les utilisateurs doivent se connecter à l’instance de destination avec un compte d’utilisateur ayant le même nom d’utilisateur ou le même identifiant utilisateur que le compte sur l’instance source. Les administrateurs peuvent passer en revue l’attribut externe qu’une instance utilise pour mapper les noms de comptes d’utilisateur à partir de données Management Console. Pour plus d’informations, consultez « Accès à la console de gestion ».