i

Description

Aiguillage ferroviaire vu de près, où la voie se sépare en deux.

Source

Xunil · page d’origine

Licence

PD Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

Git contre TFVC : comparer, migrer, faire coexister

Comparer Git et TFVC de façon notée et contextualisée, sans dogme.

En bref

• Comparer Git et TFVC de façon notée et contextualisée, sans dogme.
• Choisir selon des scénarios (équipe, dépôt, contraintes de droits, binaires, audit, CI).
• Connaître les voies de migration TFVC → Git avec ou sans historique, les outils (git-tfs, git-tf, import Azure DevOps) et leurs limites.
• Décrire la coexistence d'un dépôt Git local au-dessus d'un TFVC officiel, et ses risques.
• Disposer d'un plan de migration par étapes et d'une liste de pièges.

Prérequis : Git en profondeur, TFVC en profondeur.

Sur cette page

1. Deux philosophies
2. Équivalences de vocabulaire et de gestes
3. Comparatif noté
4. Scénarios
5. Faut-il migrer
6. Options de migration
7. Outils
8. Coexistence git local et TFVC officiel
9. Plan de migration par étapes
10. Pièges de migration
11. Contribution de l'IA
12. Voir aussi

Niveau : 🟡→🔴

Deux philosophies#

🟡 Niveau pratique

TFVC raisonne « le serveur sait » ; Git raisonne « l'historique est un graphe que chacun possède ». Ce renversement explique la plupart des difficultés de passage : plus de checkout, un commit n'est pas un check-in, la branche devient banale, l'historique est modifiable localement.

Équivalences de vocabulaire et de gestes#

🟡 Niveau pratique

Comparatif noté#

🟡 Niveau pratique

Notes /5 d'expert. Contexte : équipe de 5 à 30 développeurs, projet SQL + Power BI + scripts, dépôt de quelques Go, Azure DevOps (Server ou Services), livraisons par versions produit. Appréciations contextuelles (voir NOTATION).

Lecture : Git l'emporte nettement sur les axes « écosystème » (CI, revue, IA, recrutement, pérennité) ; TFVC garde l'avantage sur droits par chemin, binaires, simplicité. Aucun des deux ne gagne partout, et une note moyenne serait trompeuse : pondérez par vos contraintes.

Scénarios#

🟡 Niveau pratique

Faut-il migrer#

🔴 Niveau expert

Migrer a un coût : formation, outillage, risques sur l'historique et les liens work items, rupture de l'habitude. Les déclencheurs légitimes :

1. Besoin de revue de code outillée (pull requests, politiques) pour élever la qualité.
2. Besoin de CI/CD moderne sur chaque changement.
3. Pérennité : sortie d'un moteur gelé (voir 03).
4. Recrutement et montée en compétence.
5. Usage de l'IA de développement native aux plateformes Git.
6. Besoin de branches par tâche à faible coût.

Non-déclencheurs : « Git, c'est la mode », « les autres le font », un seul dev gêné par une commande. Mesurez : fréquence des conflits, durée de revue, lead time de livraison, onboarding. Une équipe sans pratique de revue sous TFVC n'en aura pas davantage sous Git.

Options de migration#

🔴 Niveau expert

Microsoft recommande la migration « tip », avec au plus un historique limité (l'outil d'import natif plafonne à 180 jours) : l'historique complet est difficile à rejouer fidèlement et peu consulté.

Points structurants à décider :

• Branches : une branche TFVC = un dossier ; les branches mortes sont à ignorer. Souvent on migre Main + les branches de release vivantes.
• Auteurs : table de correspondance DOMAINE\nom → Nom <email>.
• Work items : les liens vers changesets deviennent obsolètes ; on peut conserver les numéros dans les messages de commit migrés pour la recherche.
• Labels : deviennent des tags (si importés) ; vérifiez qu'ils ne mélangent pas des versions.
• Fichiers volumineux : à trier (LFS ? sortir du dépôt ?).
• Encodages/fins de ligne : normalisez avant l'import (06) ; sinon l'historique entier est « modifié » au premier commit de normalisation.

Outils#

🔴 Niveau expert

Exemple d'usage de git-tfs (poste Windows, Visual Studio/Team Explorer installé) :

# Historique complet d'une branche
git tfs clone https://tfs.exemple.local/tfs/Collection $/Projet/Main D:\Migration\Main --branches=none
# Historique partiel : à partir d'un changeset
git tfs clone https://tfs.exemple.local/tfs/Collection $/Projet/Main D:\Migration\Main --changeset=45000
# Auteurs
git tfs clone ... --authors=auteurs.txt
# Nettoyage avant publication : retirer les métadonnées git-tfs-id si non souhaitées
git filter-repo --message-callback "..."   # selon besoins
git remote add origin https://dev.azure.com/org/projet/_git/mon-produit
git push -u origin --all

Coexistence git local et TFVC officiel#

🔴 Niveau expert

Situation courante : l'organisation impose TFVC comme archive officielle (builds, audit), mais l'équipe veut les bénéfices de Git à son échelle : commits fréquents, branches, stash, bisect, blame, outils IA. Solution pragmatique : un dépôt git local sans remote dans le même dossier que le workspace TFVC.

Fonctionnement :

• On travaille et on commit en Git local pendant la journée (commits atomiques, historique fin).
• Aux jalons (fin de chantier, fin de journée), on archive en TFVC : tf add des nouveaux fichiers, tf checkin avec lien vers le work item.
• Les deux historiques coexistent : Git est le brouillon fin, TFVC la vérité officielle.

Règles pour que ça tienne :

1. Deux listes d'exclusion alignées : .gitignore et .tfignore ; un fichier ignoré par l'un doit l'être par l'autre (sauf cas délibéré). Voir 03.
2. Dossier .git exclu de TFVC (ne jamais l'ajouter au contrôle de source) et fichiers TFVC internes ($tf, .tf) exclus de Git.
3. Fins de ligne et encodage normalisés de la même manière des deux côtés (.gitattributes + convention TFVC), sinon chaque aller-retour provoque des diffs parasites.
4. Dates et auteurs : le commit TFVC ne reprend pas l'historique Git ; conservez des commentaires de check-in porteurs de sens, car ils sont ce que verra l'audit.
5. Droit de lecture seule en workspace TFVC : en workspace serveur, après tf get, les fichiers sont en lecture seule et il faut un tf checkout préalable avant que Git ne les modifie. En workspace local, les fichiers restent modifiables : les éditions sont détectées automatiquement, et tf reconcile /promote transforme les ajouts/suppressions faits hors de Visual Studio en modifications en attente.
6. Un seul sens d'écriture : ne jamais « synchroniser » TFVC → Git → TFVC automatiquement sans règle ; le plus sûr est tf get puis git add -A && git commit (« ce que TFVC m'a livré »), puis le travail, puis check-in.

Plan de migration par étapes#

🔴 Niveau expert

Plan type pour une équipe de 10-20 personnes, sur 6 à 12 semaines (ordre de grandeur, dépend de la taille et de la préparation) :

1. Cadrer (1 semaine) — Décider : migrer quoi (Main seule ? + releases ?), avec quel historique, pour quels bénéfices mesurables. Inventaire : taille de la collection, fichiers volumineux, branches vivantes, policies, builds, liens work items. Sponsor identifié.

2. Préparer (2-3 semaines) — Nettoyer le dépôt (binaires, caches, doublons). Normaliser encodages et fins de ligne. Rédiger .gitattributes, .gitignore, conventions de branches et de messages, politiques de branche (PR, build de validation). Établir la table des auteurs. Sécuriser les droits (groupes, dépôts découpés si droits par dossier).

3. Pilote (2 semaines) — Migrer un périmètre non critique (ou une copie du réel) avec l'outil retenu ; comparer le contenu au changeset de référence (liste de fichiers + sommes de contrôle) pour prouver la fidélité ; rejouer une livraison complète (kit installable) depuis le dépôt Git ; mesurer clone, status, build.

4. Former (en continu) — 1 session pratique de 3 h : modèle objet simplifié, cycle quotidien, PR, résolution de conflits ; fiche aide-mémoire TFVC→Git (équivalences) ; « champion Git » par équipe.

5. Basculer (1 week-end ou 1 journée calme) — Geler TFVC (droits en lecture seule), migration finale, vérification (fichiers, tags, quelques fichiers sensibles ouverts à la main), mise à jour des pipelines, hooks, documentation, liens. Communication claire : « à partir de lundi, on commit ici ».

6. Consolider (4 semaines) — Support rapproché, rétrospective, métriques (conflits, durée de revue, lead time), suppression des anciens workspaces, archivage TFVC (lecture seule, conservé).

Critères de réussite : toutes les versions produit en cours reconstructibles depuis Git ; pipeline de build vert ; plus personne ne commit en TFVC ; équipe autonome sur les opérations courantes.

Pièges de migration#

🔴 Niveau expert

Contribution de l'IA#

Prompt type : « Voici un extrait de tf history détaillé. Produis un CSV compte_tfs;nom;email sans inventer d'adresse : laisse vide si inconnue. » L'IA ne remplace ni la décision de migrer, ni la vérification de fidélité (sommes de contrôle), ni la responsabilité sur la conformité de l'archive. Voir IA et outils.

Voir aussi#

• Panorama · Git · TFVC · Stratégies de branches · SQL et BI
• Azure DevOps / TFS en profondeur · Comparatif d'outils
• Matrice : gestion de version et branches
• CI/CD pour la data · Glossaire

✻ Rédigé par Claude Sonnet 5.5