i

Description

Vue plongeante sur un grand faisceau de voies et un atelier ferroviaire sous un ciel nuageux.

Source

Telecineguy · page d’origine

Licence

CC0 Domaine public

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

Panorama des systèmes de gestion de source

Comprendre ce qu'est une gestion de source (GDS) et pourquoi elle est la colonne vertébrale de tout projet, y compris data/BI.

En bref

• Comprendre ce qu'est une gestion de source (GDS) et pourquoi elle est la colonne vertébrale de tout projet, y compris data/BI.
• Distinguer centralisé et distribué, verrouillage pessimiste et fusion optimiste, snapshots et deltas.
• Situer CVS, SVN, Perforce, Mercurial, Plastic SCM, Fossil, TFVC et Git dans l'histoire et dans leurs usages actuels.
• Savoir ce qu'est un objet versionné, un hachage, un commit, une branche.
• Disposer d'une grille de choix notée /5 pour décider de l'outil selon le contexte.

Sur cette page

1. Pourquoi une GDS
2. Vocabulaire minimal
3. Centralisé contre distribué
4. Verrouillage contre fusion
5. Snapshots contre deltas
6. Objets et hachage
7. Historique des outils
8. Les systèmes un par un
9. Grille de notation
10. Choisir
11. Pièges transverses
12. Voir aussi

Niveau : 🟢→🟡

Pourquoi une GDS#

🟢 Niveau novice

Sans GDS, on versionne par copie de dossiers (rapport_v2_final_VRAI.pbix). Cela échoue de quatre façons : on ne sait pas qui a changé quoi, on ne peut pas comparer deux états, on s'écrase à plusieurs, on ne peut pas reconstituer ce qui a été livré à un client il y a deux ans. Une GDS apporte :

1. Historique : chaque modification est enregistrée avec auteur, date, message.
2. Retour arrière : revenir à n'importe quel état passé.
3. Travail parallèle : branches, fusions.
4. Traçabilité : relier une modification à un ticket, un build, une livraison (voir CI/CD).
5. Audit : prouver ce qui a été modifié, par qui, avant telle mise en production.

Vocabulaire minimal#

Les termes sont repris dans le glossaire.

Centralisé contre distribué#

🟢 Niveau novice

Centralisé : un serveur unique détient l'historique. Le poste client n'a que la version demandée plus des métadonnées. On a besoin du serveur pour la plupart des opérations (historique, commit, branche). Exemples : CVS, SVN, Perforce, TFVC.

Distribué : chaque poste détient le dépôt complet, historique compris. Le commit est local ; on synchronise ensuite avec un ou plusieurs dépôts distants (push, pull). Exemples : Git, Mercurial, Fossil, Plastic SCM (mode distribué).

Centralisé                         Distribué
   [Serveur]                        [Dépôt A] <--> [Dépôt de référence] <--> [Dépôt B]
   /   |   \                          (historique complet partout)
 Poste Poste Poste                 
 (copie)(copie)(copie)

Verrouillage contre fusion#

🟢 Niveau novice

Deux personnes modifient le même fichier. Deux philosophies :

• Verrouillage pessimiste (lock-modify-unlock) : on « réserve » le fichier ; personne d'autre ne peut l'éditer. Avantage : pas de conflit. Inconvénient : blocage, oublis de déverrouillage, travail impossible en parallèle. Adapté aux fichiers binaires non fusionnables (.pbix, .docx, images).
• Fusion optimiste (copy-modify-merge) : chacun édite sa copie ; à l'enregistrement, l'outil fusionne et signale les conflits. Adapté aux fichiers texte.

TFVC propose les deux : checkout verrouillant (/lock:checkout) ou non (/lock:none), selon la configuration du workspace et du projet. Git ne connaît que la fusion ; pour les binaires, Git LFS apporte un verrouillage (git lfs lock) par convention de dépôt. Perforce et SVN gèrent les deux.

Snapshots contre deltas#

🟡 Niveau pratique

Deux manières de stocker l'historique :

• Deltas (CVS, SVN, TFVC, Perforce, beaucoup de systèmes historiques) : pour chaque fichier, on stocke la version de base puis les différences successives. Compact pour de petites modifications, mais reconstituer une ancienne version impose de rejouer les deltas ; la notion de « version du dépôt » est un numéro global (révision, changeset).
• Snapshots (Git) : chaque commit désigne un instantané complet de l'arborescence. Les fichiers inchangés sont simplement réutilisés par référence (même objet). Git compresse ensuite en packfiles, en calculant des deltas a posteriori entre objets proches : le modèle logique est snapshot, le stockage physique est mixte.

La différence logique compte : en modèle snapshot, comparer deux versions quelconques est direct ; le renommage n'est pas enregistré, il est déduit par similarité de contenu (Git) alors que TFVC enregistre explicitement l'opération « rename » (d'où sa capacité à suivre l'historique d'un fichier déplacé, au prix de rigidité).

Objets et hachage#

🟡 Niveau pratique

Un système moderne manipule peu de concepts : un objet contenu (le fichier), une arborescence (la liste des noms et objets), un commit (l'arborescence + parents + auteur + message). Dans Git, chaque objet est identifié par un hachage de son contenu (SHA-1 historiquement, SHA-256 en option). Conséquences :

• Intégrité : modifier un objet change son identifiant ; toute corruption est détectable.
• Déduplication : deux fichiers identiques n'occupent qu'un objet.
• Historique infalsifiable en pratique : l'identifiant d'un commit dépend de ses parents ; réécrire le passé change tous les identifiants suivants.
• Identifiants non séquentiels : pas de « révision 4217 », mais b9a971b. Les numéros séquentiels de TFVC (changeset 45815) sont plus lisibles pour les humains et les rapports.

Historique des outils#

🟡 Niveau pratique

Repère solide : Git est créé en 2005 par Linus Torvalds pour le noyau Linux ; TFVC naît avec Team Foundation Server 2005 et Visual SourceSafe en est le prédécesseur de fait chez Microsoft. Microsoft a ensuite ajouté Git à TFS (2013) et fait de Git le choix par défaut.

Les systèmes un par un#

🟡 Niveau pratique

CVS — Ancêtre. Pas de commits atomiques, pas de renommage, branches coûteuses. À migrer si rencontré.

Subversion (SVN) — Centralisé, commits atomiques, révisions globales, branches et tags par copie bon marché (/trunk, /branches, /tags par convention). Droits par chemin. Encore répandu en héritage. Bon sur les gros binaires, verrous disponibles.

Perforce Helix Core (rebaptisé Perforce P4 en 2025) — Centralisé, très performant sur dépôts énormes et binaires (jeu vidéo, matériel). Workspaces, changelists, shelving, verrouillage de fichiers, droits fins par chemin. Existe un mode Git (Helix4Git) pour coexistence. Licence commerciale.

Mercurial — Distribué, interface plus cohérente que Git, mais écosystème largement réduit (Bitbucket a retiré Mercurial en 2020). Reste utilisé dans certaines grandes organisations. Maintenance existante, adoption en baisse.

Plastic SCM (Unity Version Control) — Distribué/centralisé hybride, bon sur binaires et art de jeu, interface graphique soignée, branches par tâche. Racheté par Unity, rebaptisé Unity Version Control. Écosystème de niche.

Fossil — Distribué, un seul exécutable, inclut ticketing, wiki et forum dans le dépôt (SQLite). Idéal pour petits projets autonomes ; peu adopté en entreprise.

TFVC (Team Foundation Version Control) — Centralisé, intégré à Azure DevOps Server / Services et Visual Studio. Changesets numérotés, branches, shelvesets, check-in policies, liaison native aux work items, droits fins par chemin. Voir 03.

Git — Distribué, modèle objet par snapshots, branches triviales, écosystème inégalé. Voir 02.

Grille de notation#

🟡 Niveau pratique

Notes /5 d'expert, contexte : équipe de 5 à 30 développeurs, projet mêlant code, SQL et BI, gros dépôt de quelques Go, dépôt hébergé en entreprise. Ce sont des appréciations, pas des mesures (voir NOTATION).

Justifications clés : Git perd en apprentissage (index, rebase, HEAD détaché) mais gagne tout le reste de l'écosystème ; TFVC est simple et fin sur les droits, mais son avenir est contraint (voir 03) ; Perforce domine les dépôts massifs ; Mercurial a un bon modèle mais peu de plateformes.

Choisir#

🔴 Niveau expert

Arbre de décision simplifié :

Critères de décision à poser avant le choix de l'outil :

1. Taille et nature des fichiers : majoritairement texte (SQL, TMDL, JSON) → Git excellent. Majoritairement binaires de centaines de Mo → Perforce/Plastic, ou Git + LFS avec discipline.
2. Modèle de droits : séparer l'accès par dossier pour des sous-traitants ? Git exige des dépôts séparés ; TFVC le fait nativement.
3. Compétences : qui forme les juniors ? Le marché de l'emploi et la documentation penchent massivement pour Git.
4. Chaîne de livraison : pipelines, revues de code par pull request, politiques de branche : Git est le chemin le moins coûteux.
5. Horizon de support : une GDS en fin d'investissement fait porter un risque de dette.
6. Coût de migration : historique à conserver ? liens work items ? labels ? droits ?

Pièges transverses#

🔴 Niveau expert

• ⚠️ Piège — Confondre sauvegarde et versionnement : une GDS n'est pas une sauvegarde sans réplication ; sauvegardez le serveur (base de collection TFVC, dépôts distants).
• ⚠️ Piège — Commits fourre-tout : un commit mélangeant correctif, reformatage et nouvelle fonctionnalité rend l'audit et le revert inutilisables. Un commit = un sujet.
• ⚠️ Piège — Données dans le dépôt : tables de référence volumineuses, exports, sauvegardes .bak, secrets. Voir 06.
• ⚠️ Piège — Branches longues : plus une branche vit, plus la fusion coûte (le coût croît plus vite que le temps). Voir 05.
• ⚠️ Piège — Encodage et fins de ligne non normalisés : des diffs « de tout le fichier » et des accents corrompus. Voir 06.

Voir aussi#

• Git en profondeur · TFVC en profondeur · Git vs TFVC
• Azure DevOps / TFS en profondeur
• Matrice : gestion de version et branches
• CI/CD · Glossaire

✻ Rédigé par Claude Sonnet 5.5