Informations sur les migrations entre les produits GitHub

À propos des migrations entre produits GitHub

Avec GitHub Enterprise Importer, vous pouvez migrer des données de GitHub Enterprise Server à GitHub Enterprise Cloud, ou migrer des données d’un compte à l’autre sur GitHub Enterprise Cloud. Pour plus d’informations, consultez « À propos de GitHub Enterprise Importer ».

Si votre source de migration est un autre compte sur GitHub.com, vous pouvez migrer des référentiels individuels entre les organisations ou des organisations entières entre les entreprises. Si votre source de migration est GitHub Enterprise Server, vous pouvez migrer des dépôts.

Les données que GitHub Enterprise Importer migre dépendent de la source de la migration et de ce que vous migrez, à savoir un référentiel ou une organisation.

Données migrées à partir de GitHub Enterprise Server

git clone --mirror OLD-REPOSITORY-URL
cd OLD-REPOSITORY-NAME
git remote add new-origin NEW-REPOSITORY-URL
git push new-origin --mirror

git clone --mirror OLD-REPOSITORY-URL
cd OLD-REPOSITORY-NAME
git remote add new-origin NEW-REPOSITORY-URL
git push new-origin --mirror

Pour migrer à partir de GitHub Enterprise Server (GHES), vous devez avoir GHES version 3.4.1 ou ultérieure. Les données migrées dépendent de la version que vous utilisez.

Différentes limites de taille par dépôt s’appliquent en fonction de votre version de GHES.

Données non migrées

Actuellement, les données suivantes ne sont pas migrées.

• Résultats Code scanning
• Vérifications de l’état de la validation
• Les alertes Dependabot
• Les secrets Dependabot
• Les discussions au niveau du dépôt
• Modifier l’historique des commentaires de problème et des commentaires de demande de tirage
• Les relations de duplication entre les dépôts (voir « À propos des duplications (fork) »)
• Les secrets GitHub Actions, les variables, les environnements, les exécuteurs auto-hébergés, les exécuteur plus grand ou l’historique des exécutions de flux de travail
• Applications GitHub et installations d’applications GitHub
• Les objets Git LFS et les grands binaires (les dépôts utilisant Git LFS sont toujours pris en charge, voir « Limitations de GitHub Enterprise Importer »)
• Les packages dans GitHub Packages
• Les projets (classiques) au niveau de l’organisation
• Projects (la nouvelle expérience des projets)
• Références entre les demandes de tirage et les problèmes dans différents référentiels (consultez « Références et URL automatiquement liées »)
• Les états de correction des résultats d’secret scanning
• Référentiels appartenant à des comptes d’utilisateur
• Propriétés du référentiel
• Étoiles de référentiel
• Observateurs de référentiels
• Ensembles de règles
• Règles de protection des étiquettes
• Profils utilisateurs, clés SSH, clés KSK ou personal access tokens
• Secrets de webhook
• Équipes
• Accès des utilisateurs ou des équipes au dépôt
• Paramètres de dépôt pour les demandes de tirage

Protections de branche

Les protections de branches appliquent un ensemble de règles spécifié à un nom de branche ou à un modèle de nom de branche spécifique. Pour plus d’informations, consultez « À propos des branches protégées ».

Les protections de branches seront toujours migrées, mais certaines règles ne seront pas migrées. Les règles de protection de branche suivantes ne sont pas migrées.

• Autoriser des acteurs spécifiques à contourner les demandes de tirage requises
• Exiger l’approbation de la poussée la plus récente
• Exiger que les déploiements réussissent avant de fusionner
• Verrouiller une branche
• Limiter les poussées qui créent des branches correspondantes
• Autoriser les envois (push) forcés

Les limitations suivantes s'appliquent également :

• Si une règle de protection de branches vous permet éventuellement de spécifier des personnes, des équipes ou des applications qui sont exemptées de la règle, par exemple « Restreindre qui peut ignorer les révisions de demande de tirage », les exceptions ne sont pas migrées.
• Si la règle « Autoriser les poussées forcées » est activée en mode « Spécifier qui peut forcer la poussée », la règle n’est pas migrée.

Données migrées à partir d’autres comptes sur GitHub.com

Si votre source de migration est un autre compte sur GitHub.com, vous pouvez migrer des référentiels individuels entre les organisations ou des organisations entières entre les entreprises.

Données migrées pour une organisation

Lorsque vous migrez une organisation, une nouvelle organisation est créée dans le compte d’entreprise de destination. Ensuite, les données suivantes sont migrées vers la nouvelle organisation.

• Équipes
• Dépôts
• Accès des équipes aux dépôts
• Privilèges des membres
• Webhooks au niveau de l’organisation (doivent être réactivés après votre migration, consultez « Activation des webhooks »)
• Nom de la branche par défaut pour les nouveaux dépôts créés dans l’organisation

Tous les dépôts sont migrés avec une visibilité privée. Si vous souhaitez définir la visibilité d’un dépôt sur public ou interne, vous pouvez le faire après la migration en utilisant l’interface utilisateur ou l’API.

Les appartenances aux équipes ne sont pas migrées. Après la migration, vous devrez ajouter des membres aux équipes migrées. Pour plus d’informations, consultez « Vue d’ensemble d’une migration entre produits GitHub ».

Données migrées pour un référentiel

Lorsque vous migrez un dépôt, directement ou dans le cadre d’une migration d’organisation, seules les données suivantes sont migrées.

• Source Git (y compris l’historique des commits)
• Demandes de tirage
• Problèmes
• Étapes majeures
• Wikis (sauf les pièces jointes)
• Workflows GitHub Actions
• Commentaires de commit
• Webhooks actifs (doivent être réactivés après votre migration, consultez « Activation des webhooks »)
• Rubriques sur les dépôts
• Paramètres du référentiel
  • Protections de branches (voir « Protections de branches » pour plus d’informations)
  • Paramètres GitHub Pages
  • Références de lien automatique
  • Paramètres GitHub Advanced Security
  • Paramètres de demande de tirage
    • Supprimer automatiquement les branches principales
    • Autoriser la fusion automatique
    • Autoriser les commits de fusion (le paramètre de message de commit est réinitialisé au message par défaut)
    • Autoriser la fusion Squash (le paramètre de message de commit est réinitialisé au message par défaut)
    • Autoriser la fusion de rebasage
• Mises en production (jusqu’à 10 Go par dépôt)
• Historique utilisateur pour les données ci-dessus
• Pièces jointes (consultez « Joindre des fichiers »)

Données non migrées

Actuellement, les données suivantes ne sont pas migrées.

• Secrets Codespaces * Résultats Code scanning
• Vérifications de l’état de la validation
• Les alertes Dependabot
• Les secrets Dependabot
• Les discussions au niveau du dépôt
• Modifier l’historique des commentaires de problème et des commentaires de demande de tirage
• Les relations de duplication entre les dépôts (voir « À propos des duplications (fork) »)
• Les secrets GitHub Actions, les variables, les environnements, les exécuteurs auto-hébergés, les exécuteur plus grand ou l’historique des exécutions de flux de travail
• Applications GitHub et installations d’applications GitHub
• Les objets Git LFS et les grands binaires (les dépôts utilisant Git LFS sont toujours pris en charge, voir « Limitations de GitHub Enterprise Importer »)
• Les packages dans GitHub Packages
• Les projets (classiques) au niveau de l’organisation
• Projects (la nouvelle expérience des projets)
• Références entre les demandes de tirage et les problèmes dans différents référentiels (consultez « Références et URL automatiquement liées »)
• Les états de correction des résultats d’secret scanning
• Référentiels appartenant à des comptes d’utilisateur
• Propriétés du référentiel
• Étoiles de référentiel
• Observateurs de référentiels
• Ensembles de règles
• Règles de protection des étiquettes
• Profils utilisateurs, clés SSH, clés KSK ou personal access tokens
• Secrets de webhook
• Accès utilisateur au dépôt

Lorsque vous migrez un dépôt directement, les équipes et l’accès des équipes aux dépôts ne sont pas migrés.

Protections de branche

Les protections de branches appliquent un ensemble de règles spécifié à un nom de branche ou à un modèle de nom de branche spécifique. Pour plus d’informations, consultez « À propos des branches protégées ».

Les protections de branches seront toujours migrées, mais certaines règles ne seront pas migrées. Les règles de protection de branche suivantes ne sont pas migrées.

• Autoriser des acteurs spécifiques à contourner les demandes de tirage requises
• Exiger l’approbation de la poussée la plus récente
• Exiger que les déploiements réussissent avant de fusionner
• Verrouiller une branche
• Limiter les poussées qui créent des branches correspondantes
• Autoriser les envois (push) forcés

Les limitations suivantes s'appliquent également :

• Si une règle de protection de branches vous permet éventuellement de spécifier des personnes, des équipes ou des applications qui sont exemptées de la règle, par exemple « Restreindre qui peut ignorer les révisions de demande de tirage », les exceptions ne sont pas migrées.
• Si la règle « Autoriser les poussées forcées » est activée en mode « Spécifier qui peut forcer la poussée », la règle n’est pas migrée.

Limitations relatives aux données migrées

Il existe des limites à ce que GitHub Enterprise Importer peut migrer. Certaines sont dues à des limitations de GitHub, tandis que d’autres sont des limitations de GitHub Enterprise Importer lui-même.

Limitations de GitHub

• Taille limite de 2 Go pour un commit Git : Aucun commit de votre dépôt Git ne peut dépasser 2 Go. Si l’un de vos commits dépasse 2 Go, vous devez le diviser en commits plus petits de 2 Go chacun ou moins.
• Limite de 255 octets pour les références Git : Aucune référence Git, communément appelée « ref », ne peut avoir un nom qui dépasse 255 octets. En règle générale, cela signifie que vos références ne peuvent pas contenir plus de 255 caractères, mais tous les caractères non-ASCII, tels que les emojis, peuvent consommer plus d’un octet. Si l’une de vos références Git est trop grande, nous retournons un message d’erreur clair.
• Taille limite de fichier de 100 Mo : Aucun fichier dans votre dépôt Git ne peut dépasser 100 Mo. Envisagez d’utiliser Git LFS pour stocker des gros fichiers. Pour plus d’informations, consultez « Gestion des fichiers volumineux ».

Limitations de GitHub Enterprise Importer

• Taille limite de 10 Go pour un dépôt Git : Cette limite s’applique uniquement au code source. Pour vérifier si l’archive du référentiel dépasse la limite, utilisez l’outil git-sizer et passez en revue la taille totale de l’objet blob dans la sortie. L’outil git-sizer permet également d’identifier les problèmes potentiels liés aux fichiers volumineux, à la taille d’objet blob, à la taille de validation et aux nombres d’arborescences susceptibles d’avoir un impact sur les migrations.
• Limite de 10 Go pour les métadonnées : Importer ne peut pas migrer les dépôts qui ont plus de 10 Go de métadonnées. Les métadonnées comprennent les problèmes, les demandes de tirage, les mises en production et les pièces jointes. Dans la plupart des cas, les métadonnées volumineuses sont dues aux ressources binaires attachées aux mises en production. Vous pouvez exclure des mises en production de la migration avec l’indicateur --skip-releases de la commande migrate-repo, puis déplacer vos mises en production manuellement après la migration.
• Objets Git LFS non migrés : Importer peut migrer les dépôts qui utilisent Git LFS, mais les objets LFS eux-mêmes ne seront pas migrés. Ils peuvent être poussés vers votre destination de migration en tant que tâche de suivi une fois la migration terminée. Pour plus d’informations, consultez « Duplication d’un dépôt ».
• Tâches de suivi requises : Lors de la migration entre produits GitHub, certains paramètres ne sont pas migrés et doivent être reconfigurés dans le nouveau dépôt. Pour obtenir la liste des tâches de suivi que vous devrez effectuer après chaque migration, consultez « Vue d’ensemble d’une migration entre produits GitHub ».
• Fonctionnalité de recherche de code différée : La réindexation de l’index de recherche peut prendre quelques heures après la migration d’un dépôt, et les recherches de code peuvent retourner des résultats inattendus tant que la réindexation n’est pas terminée.
• Les ensembles de règles configurés pour votre organisation peuvent entraîner l’échec des migrations : Par exemple, si vous avez configuré une règle qui exige que les adresses e-mail des auteurs de commit se terminent par @monalisa.cat, et que le dépôt que vous migrez contient des commits qui ne sont pas conformes à cette règle, votre migration échoue. Pour plus d’informations sur les ensembles de règles, consultez « À propos des ensembles de règles ».
• Le contenu de mannequin ne peut pas être recherchable : les mannequins sont des utilisateurs d’espace réservé auxquels le contenu importé (tels que les problèmes, les demandes de tirage, les commentaires, etc.) est associé. Lorsque vous recherchez du contenu associé à un mannequin, tel que des problèmes attribués, ces problèmes peuvent ne pas être trouvés. Une fois qu’un mannequin est récupéré, le contenu doit être trouvé via le nouveau propriétaire. Pour plus d’informations, consultez « Récupération de mannequins pour GitHub Enterprise Importer ».

Mise en route

Avant de migrer entre les produits GitHub, vous devez planifier la façon dont vous allez exécuter votre migration. Avant de migrer des données, vous devez choisir quelqu’un pour exécuter la migration. Vous devez accorder à cette personne l’accès nécessaire pour la source et la destination de la migration. Nous vous recommandons également d’exécuter une migration d’évaluation gratuite en premier.

Pour obtenir une vue d’ensemble du processus de migration du début à la fin, consultez « Vue d’ensemble d’une migration entre produits GitHub ».