Informations sur les migrations entre les 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

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.

Article	GHES 3.4.1+	GHES 3.5.0+
Source Git (y compris l’historique des commits)
Requêtes de tirage
Problèmes
Étapes majeures
Wikis
Projets (classiques) au niveau du dépôt
Workflows GitHub Actions
Commentaires de commit
Webhooks actifs
Protections de branche
Paramètres GitHub Pages
Historique utilisateur pour les données ci-dessus
Pièces jointes (consultez « Joindre des fichiers »)
Versions

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

Limite	GHES <3.8.0	GHES 3.8.0+
Source Git	2 Go	10 Go
Métadonnées	2 Go	10 Go

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

Tous les Projects (beta) (nouvelle expérience de projet)
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
Les secrets GitHub Codespaces
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
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'utilisateurs
Propriétés du référentiel (bêta publique)
É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 ».

Remarque : Les références à des équipes, telles que @octo-org/octo-team, ne sont pas mises à jour dans le cadre d’une migration d’organisation. Cela risque d’entraîner des problèmes dans l’organisation de destination, comme par exemple les fichiers CODEOWNERS qui ne fonctionnent pas comme prévu. Pour plus d’informations sur la façon de prévenir et de résoudre ces problèmes, consultez « Résolution des problèmes de votre migration avec GitHub Enterprise Importer ».

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)
Projets (classiques) au niveau du dépôt
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 »)

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

Tous les Projects (beta) (nouvelle expérience de projet)
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
Les secrets GitHub Codespaces
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
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'utilisateurs
Propriétés du référentiel (bêta publique)
É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.com, tandis que d’autres sont des limitations de GitHub Enterprise Importer lui-même.

Limitations de GitHub.com

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 ».

Bien démarrer

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 ».

Informations sur les migrations entre les produits GitHub

Dans cet article