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 vers GitHub Enterprise Cloud, ou migrer des données de GitHub.com vers un autre compte sur GitHub Enterprise Cloud.

Par exemple, GitHub Enterprise Importer peut aider votre entreprise à :

Adopter GitHub Enterprise Cloud avec résidence des données en migrant votre entreprise vers GHE.com
Adopter certaines fonctionnalités sur GitHub.com, telles que Enterprise Managed Users ou de nouveaux modèles de facturation, en migrant entre entreprises sur GitHub.com
Bénéficier d'une administration simplifiée et de nouvelles fonctionnalités en migrant de GitHub Enterprise Server vers GitHub Enterprise Cloud

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

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

Si l’organisation de destination ou l’entreprise a des ensembles de règles activés, l’historique du référentiel migré peut violer ces règles. Pour autoriser la migration sans désactiver vos ensembles de règles, ajoutez « Migrations de référentiels » à la liste de contournement pour chaque ensemble de règles applicable. Ce contournement s’applique uniquement pendant la migration. Une fois terminés, les ensembles de règles seront appliqués à toutes les nouvelles contributions.

Pour configurer le contournement :

Accédez à chaque ensemble de règles d’entreprise ou d’organisation.
Dans la section « Liste de contournement », cliquez sur Ajouter un contournement.
Sélectionnez Migrations de référentiels.

Pour plus d’informations, consultez « Création d'ensembles de règles pour les dépôts de votre organisation ».

Considérations relatives aux migrations vers GitHub Enterprise Cloud

Avant d'utiliser GitHub Enterprise Importer, tenez compte des considérations suivantes :

Si vous utilisez déjà GitHub Enterprise Cloud : Un GitHub Enterprise vous donne droit à un déploiement de GitHub Enterprise Cloud.

Par exemple, si vous utilisez déjà GitHub.com, et que vous souhaitez également migrer de GitHub Enterprise Server vers GHE.com, un seul plan ne suffira pas à couvrir votre utilisation des deux.
Si vous migrez vers Enterprise Managed Users : Vous devrez intégrer un fournisseur d’identité pour gérer les comptes d’utilisateur. Vérifiez le niveau d’assistance de votre fournisseur d’identité avant de commencer. Consultez À propos d’Enterprise Managed Users.
Si vous migrez à partir de GitHub Enterprise Server : Sachez que GitHub applique des limites de débit à certaines actions, désactivées par défaut sur GitHub Enterprise Server. Consultez Limites de débit pour l'API REST.
Si vous migrez vers GitHub Enterprise Cloud avec résidence des données : Sachez que certaines fonctionnalités ne sont pas disponibles et que d’autres nécessitent une configuration différente ou supplémentaire. Consultez Vue d’ensemble des fonctionnalités pour GitHub Enterprise Cloud avec résidence des données.

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.

Élément	GHES 3.4.1+	GHES 3.5.0+
Source Git (y compris l’historique des commits)
Demandes de tirage
Problèmes
Jalons
Wikis
Workflows GitHub Actions
Commentaires de commit
Webhooks (doivent être réactivés après votre migration, consultez « Activation des webhooks »)
Protections de branche
Paramètres GitHub Pages
Historique utilisateur pour les données ci-dessus
Pièces jointes (consultez « Joindre des fichiers »)
Publications

Des limites de taille par référentiel différentes s’appliquent à l’archive compressée en fonction de votre version de GHES.

Limite	Version du GHES inférieure à 3.8.0	GHES 3.8.x-3.11.x	GHES 3.12.x	GHES 3.13.0+
Source Git	2 GiO	10GiB	20GiB	40 Go (préversion publique)
Métadonnées	2 GiO	10GiB	20GiB	40 Go (préversion publique)

Données non migrées

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

Journaux d’audit
Code scanning Résultats
Codespaces Secrets
Vérifications de l’état de commit
Dependabot Alertes
Dependabot Secrets
Les discussions au niveau du dépôt
Modifier l’historique des commentaires sur le problème et sur la demande de tirage
Relations de duplication entre les dépôts (voir À propos des forks)
GitHub Actions secrets, variables, environnements, agents auto-hébergés, exécuteur plus grands, artefacts de workflow ou historique des exécutions de workflow
GitHub Apps et installations de GitHub Apps
Git LFS objets et fichiers binaires volumineux (les référentiels utilisant Git LFS sont toujours pris en charge, voir Limitations de GitHub Enterprise Importer)
Liens de commits vers des demandes de tirage fusionnées par rebase
Mentions des utilisateurs, des équipes et des organisations dans les demandes de tirage, les problèmes, les versions et les commentaires (le nom d’utilisateur mentionné à l’origine est conservé)
Les packages dans GitHub Packages
Projets (classiques) au niveau de l’organisation
Projects (nouvelle expérience de projets)
Références entre les demandes de tirage et les problèmes dans différents dépôts (voir Références et URL automatiquement liées)
États de correction des secret scanning résultats
Dépôts appartenant à des comptes d’utilisateurs
Flux d’activité du dépôt
Propriétés du référentiel et propriétés personnalisées (voir Propriétés personnalisées)
Étoiles du dépôt
Observateurs du dépôt
Ensembles de règles
Sous-problèmes (voir À propos des problèmes)
Règles de protection des étiquettes
Accès utilisateur au dépôt
Profils des utilisateurs, clés SSH, clés de signature ou personal access tokens
Secrets de webhook
Teams
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 depuis GitHub.com

Si votre source de migration est un compte sur GitHub.com, vous pouvez migrer des référentiels individuels entre organisations, ou migrer des organisations entières entre 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.

Teams
Référentiels
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 liés à 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
Jalons
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 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 Gio 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.

Journaux d’audit
Code scanning Résultats
Codespaces Secrets
Vérifications de l’état de commit
Dependabot Alertes
Dependabot Secrets
Les discussions au niveau du dépôt
Modifier l’historique des commentaires sur le problème et sur la demande de tirage
Relations de duplication entre les dépôts (voir À propos des forks)
GitHub Actions secrets, variables, environnements, agents auto-hébergés, exécuteur plus grands, artefacts de workflow ou historique des exécutions de workflow
GitHub Apps et installations de GitHub Apps
Git LFS objets et fichiers binaires volumineux (les référentiels utilisant Git LFS sont toujours pris en charge, voir Limitations de GitHub Enterprise Importer)
Liens de commits vers des demandes de tirage fusionnées par rebase
Mentions des utilisateurs, des équipes et des organisations dans les demandes de tirage, les problèmes, les versions et les commentaires (le nom d’utilisateur mentionné à l’origine est conservé)
Les packages dans GitHub Packages
Projets (classiques) au niveau de l’organisation
Projects (nouvelle expérience de projets)
Références entre les demandes de tirage et les problèmes dans différents dépôts (voir Références et URL automatiquement liées)
États de correction des secret scanning résultats
Dépôts appartenant à des comptes d’utilisateurs
Flux d’activité du dépôt
Propriétés du référentiel et propriétés personnalisées (voir Propriétés personnalisées)
Étoiles du dépôt
Observateurs du dépôt
Ensembles de règles
Sous-problèmes (voir À propos des problèmes)
Règles de protection des étiquettes
Accès utilisateur au dépôt
Profils des utilisateurs, clés SSH, clés de signature ou personal access tokens
Secrets de webhook

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

Limite de taille de 2 Gio pour une validation Git unique : Aucune validation unique dans votre référentiel Git ne peut être supérieure à 2 Gio. Si l’une de vos validations est supérieure à 2 Gio, vous devez fractionner la validation en validations plus petites qui sont chacune de 2 Gio ou plus petites.
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.
Limite de taille de fichier MiB 100 : Une fois votre migration terminée, aucun fichier unique dans votre référentiel Git ne peut être supérieur à 100 Mio. Pendant la migration du référentiel, cette limite est augmentée à 400 Mio. Envisagez d’utiliser Git LFS pour stocker les fichiers volumineux. Pour plus d’informations, consultez « Gestion des fichiers volumineux ».

Limitations de GitHub Enterprise Importer

Limite de taille de 40 Go pour un référentiel Git (préversion publique) : 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 40 Gio pour les métadonnées (préversion publique) : Le Importer ne peut pas migrer les référentiels contenant plus de 40 Gio 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 migrate-repo de la commande --skip-releases, puis déplacer vos mises en production manuellement après la migration.
** Limite de taille de fichier de 400 Mo :** lors de la migration d’un référentiel avec GitHub Enterprise Importer, aucun fichier de votre référentiel Git ne peut dépasser 400 Mo. Envisagez d’utiliser Git LFS pour stocker des gros fichiers. Pour plus d’informations, consultez « Gestion des fichiers volumineux ».
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 modèles 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 à la source et à la destination de la migration. Nous vous recommandons également d’exécuter d’abord une migration d’essai.

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