Importez et migrez des référentiels de TFVC vers Git

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Vous pouvez migrer du code à partir d’un référentiel TFVC existant vers un nouveau référentiel Git au sein de la même organisation. La migration vers Git est un processus impliqué pour les grands référentiels et équipes TFVC. Les systèmes de contrôle de version centralisés, comme TFVC, se comportent différemment de Git de manière fondamentale. Le commutateur implique beaucoup plus que d’apprendre de nouvelles commandes. Il s’agit d’un changement perturbant qui nécessite une planification minutieuse. Vous devez réfléchir à ce qui suit :

• Révision des outils et des processus
• Suppression de fichiers binaires et d’exécutables
• Formation de votre équipe

Avant de commencer la migration, nous vous recommandons vivement de lire Contrôle de version centralisé vers Git et la section suivante Migrer de TFVC vers Git.

L’expérience d’importation est idéale pour les petits référentiels TFVC simples. Cette recommandation est également applicable aux référentiels qui ont déjà été « nettoyés », comme indiqué dans Contrôle de version centralisé vers Git et dans la section suivante Migrer de TFVC vers Git. Ces sections recommandent en outre d'autres outils pour une configuration plus avancée des référentiels TFVC.

Important

En raison des différences dans la façon dont TFVC et l’historique du contrôle de version du magasin Git, nous vous recommandons de ne pas migrer votre historique. Il s’agit de l’approche adoptée par Microsoft pour la migration de Windows et d’autres produits de la gestion de version centralisée vers Git.

Importation du référentiel

1. Sélectionnez Référentiels, Fichiers.

   

2. Dans la liste déroulante du référentiel, sélectionnez Importer les référentiels.

   

3. Sélectionnez TFVC dans la liste déroulante Type de source

4. Tapez le chemin d’accès au dépôt/branche/dossier que vous souhaitez importer dans le référentiel Git. Par exemple : $/Fabrikam/FabrikamWebsite

5. Si vous souhaitez migrer l’historique à partir du référentiel TFVC, cliquez sur Migrer l’historique et sélectionnez le nombre de jours. Vous pouvez migrer jusqu’à 180 jours d’historique à partir du jeu de modifications le plus récent. Un lien vers le référentiel TFVC est ajouté dans le message de commit du 1er ensemble de modifications migré vers Git. Cela facilite la recherche d’un historique plus ancien si nécessaire.

6. Donnez un nom au nouveau référentiel Git, puis cliquez sur Importer. Selon la taille de l’importation, votre référentiel Git est prêt en quelques minutes.

   

Dépannage

Cette expérience est optimisée pour les petits référentiels TFVC simples ou les référentiels qui ont été préparés pour une migration. Cela signifie qu’il présente quelques limitations.

1. Il migre uniquement le contenu de la racine ou d’une branche. Par exemple, si vous avez un projet TFVC auquel $/Fabrikam se trouve 1 branche et 1 dossier sous celui-ci, un chemin d’accès à l’importation $/Fabrikam importerait le dossier alors qu’il $/Fabrikam/<branch> n’importerait que la branche.
2. Le référentiel importé et l’historique associé (si importé) ne peuvent pas dépasser 1 Go de taille.
3. Vous pouvez également importer jusqu’à 180 jours d’historique.

Si l'une des limitations précédentes constitue un obstacle à votre importation, nous vous recommandons d’essayer des outils externes tels que Git-TFS pour l’importation et la lecture de nos livres blancs - Contrôle de version centralisé vers Git et la section suivante Migrer de TFVC vers Git.

Important

L’utilisation d’outils externes tels que Git-TFS avec des produits, des services ou des plateformes Microsoft relève de l'entière responsabilité de l’utilisateur. La fonctionnalité, la fiabilité et la sécurité de ces extensions tierces ne sont en aucun cas approuvées, prises en charge ou garanties par Microsoft.

Migrer de TFVC vers Git

Avant de migrer le code source d’un système de contrôle de version centralisé vers Git, découvrez les différences entre les deux, puis préparez la migration.

• Exigences
• Étapes de migration
  • Consultez la dernière version
  • Supprimer des fichiers binaires et des outils de génération
  • Convertir la configuration spécifique au contrôle de version
  • Enregistrer les modifications et effectuer la migration
  • Migrations avancées
• Mettre à jour le flux de travail

Spécifications

Afin de faciliter les migrations, la section précédente de cet article contient un certain nombre d'exigences qui doivent être remplies avant de suivre la procédure Importation de référentiel.

• Migrer une seule branche. Lors de la planification de migration, choisissez une nouvelle stratégie de branchement pour Git. La migration uniquement de la branche principale prend en charge un flux de travail basé sur des branches de rubriques comme GitFlow ou GitHub Flow.
• Faites une astuce pour la migration, par exemple, importez uniquement la dernière version du code source. Si l’historique TFVC est simple, il existe une option permettant de migrer une partie de l'historique, jusqu’à 180 jours, afin que l’équipe puisse travailler uniquement depuis Git. Pour plus d’informations, consultez Planifier votre migration vers Git.
• Excluez les ressources binaires telles que les images, les jeux de données scientifiques, ou les modèles de jeu du dépôt. Ces ressources doivent utiliser l’extension Git LFS (stockage de fichiers volumineux), que l’outil d’importation ne configure pas.
• Conservez le dépôt importé en dessous de 1 Go de taille.

Si le dépôt ne répond pas à ces exigences, utilisez l’outil Git-TFS pour effectuer votre migration à la place.

Important

L’utilisation d’outils externes tels que Git-TFS avec des produits, des services ou des plateformes Microsoft relève de l'entière responsabilité de l’utilisateur. La fonctionnalité, la fiabilité et la sécurité de ces extensions tierces ne sont en aucun cas approuvées, prises en charge ou garanties par Microsoft.

Étapes de migration

Le processus de migration à partir de TFVC est généralement simple :

1. Consultez la dernière version de la branche à partir de TFVC sur votre disque local.
2. Supprimez les fichiers binaires et les outils de génération du référentiel et configurez un système de gestion des packages comme NuGet.
3. Convertissez des directives de configuration spécifiques au contrôle de version. Par exemple, convertissez .tfignore des fichiers en .gitignore, et convertissez .tpattributes des fichiers en .gitattributes.
4. Enregistrez les modifications et effectuez la migration vers Git.

Les étapes 1 à 3 sont facultatives. S’il n’existe pas de fichiers binaires dans le référentiel et qu’il n’est pas nécessaire de configurer un .gitignore ou un .gitattributes, vous pouvez passer directement à l'étape Enregistrer les modifications et effectuer la migration.

Consultez la dernière version

Créez un espace de travail TFS et mappez un dossier de travail pour le répertoire du serveur en cours de migration vers Git. Cela ne nécessite pas de mappage complet des dossiers de travail. Seuls les dossiers de mappage qui contiennent des binaires à supprimer du dépôt et les dossiers qui contiennent des fichiers de configuration spécifiques au système de contrôle de version comme .tfignore.

Une fois les mappages configurés, obtenez le dossier localement :

tf get /version:T /recursive

Supprimer des fichiers binaires et des outils de génération

En raison de la façon dont Git stocke l’historique des fichiers modifiés en fournissant une copie de chaque fichier dans l’historique à chaque développeur, l'enregistrement des fichiers binaires directement dans le dépôt entraîne une croissance rapide du dépôt et peut entraîner des problèmes de performances.

Pour créer des outils et des dépendances tels que des bibliothèques, adoptez une solution d’empaquetage avec prise en charge du contrôle de version, telle que NuGet. De nombreux outils et bibliothèques open source sont déjà disponibles dans la galerie NuGet, mais pour les dépendances propriétaires, créez de nouveaux packages NuGet.

Une fois que les dépendances sont déplacées dans NuGet, assurez-vous qu’elles ne sont pas incluses dans le dépôt Git en les ajoutant à .gitignore.

Convertir la configuration spécifique au contrôle de version

Team Foundation Version Control fournit un .tfignore fichier, qui garantit que certains fichiers ne sont pas ajoutés au dépôt TFVC. Vous pouvez utiliser le .tfignore fichier pour les fichiers générés automatiquement, comme la sortie de build, afin qu’ils ne soient pas enregistrés accidentellement.

Si le projet s’appuie sur ce comportement, convertissez le .tfignore fichier en un .gitignore fichier.

Les clients TFVC multiplateformes prennent également en charge un .tpattributes fichier qui contrôle la façon dont les fichiers sont placés sur le disque local ou enregistrés dans le dépôt. Si un .tpattributes fichier est en cours d’utilisation, convertissez-le en un .gitattributes fichier.

Enregistrer les modifications et effectuer la migration

Enregistrez les modifications qui suppriment les fichiers binaires, migrez vers la gestion des packages ou convertissez la configuration spécifique au contrôle de version. Une fois que vous apportez cette dernière modification dans TFVC, vous pouvez effectuer l’importation.

Suivez la procédure Importation du référentiel pour effectuer l’importation.

Migrations avancées

L’outil Git-TFS est un pont bidirectionnel entre Team Foundation Version Control et Git, et vous pouvez l’utiliser pour effectuer une migration. Git-TFS est approprié pour une migration avec un historique complet, plus de 180 jours que l’outil Import prend en charge. Vous pouvez également utiliser Git-TFS pour tenter une migration qui inclut plusieurs branches et relations de fusion.

Avant d’essayer une migration avec Git-TFS, notez qu’il existe des différences fondamentales entre la façon dont TFVC et Git stockent l’historique :

• Git stocke l’historique en tant qu’instantané du dépôt dans le temps, tandis que TFVC enregistre les opérations discrètes qui se sont produites sur un fichier. Les types de modification dans TFVC comme renommer, annuler la suppression et restaurer ne peuvent pas être exprimés dans Git. Au lieu de voir que ce fichier A a été renommé en fichier B, il effectue uniquement le suivi de ce fichier A a été supprimé et le fichier B a été ajouté dans la même validation.
• Git n’a pas d’analogue direct d’une étiquette TFVC. Les étiquettes peuvent contenir n’importe quel nombre de fichiers à n’importe quelle version spécifique et refléter des fichiers à différentes versions. Bien que conceptuellement similaires, les balises Git pointent vers un instantané de l’ensemble du dépôt à un moment donné. Si le projet s’appuie sur des étiquettes TFVC pour savoir ce qui a été remis, les balises Git peuvent ne pas fournir ces informations.
• Les fusions dans TFVC se produisent au niveau du fichier, et non au niveau du dépôt entier. Seul un sous-ensemble de fichiers modifiés peut être fusionné d’une branche à une autre. Les fichiers modifiés restants peuvent ensuite être fusionnés dans un ensemble de modifications ultérieur. Dans Git, une fusion affecte l’ensemble du dépôt, et les deux ensembles de modifications individuelles ne peuvent pas être considérés comme une fusion.

En raison de ces différences, il est recommandé d’effectuer une astuce de migration et de conserver votre dépôt TFVC en ligne, mais en lecture seule, afin d’afficher l’historique.

Pour tenter une migration avancée avec Git-TFS, consultez cloner une branche unique avec l’historique ou cloner toutes les branches avec l’historique de fusion.

Important

L’utilisation d’outils externes tels que Git-TFS avec des produits, des services ou des plateformes Microsoft relève de l'entière responsabilité de l’utilisateur. La fonctionnalité, la fiabilité et la sécurité de ces extensions tierces ne sont en aucun cas approuvées, prises en charge ou garanties par Microsoft.

Mettre à jour le flux de travail

Le passage d’un système de contrôle de version centralisé à Git ne consiste pas seulement à migrer du code. L’équipe a besoin de formation pour comprendre en quoi Git est différent du système de contrôle de version existant et comment ces différences affectent le travail quotidien.

En savoir plus sur la migration du contrôle de version centralisé vers Git.