Historique du contrôle de version : de RCS à Git

Git est un système de contrôle de version distribué. Mais pour comprendre ce que “distribué” signifie (et pourquoi c’est un avantage), il faut connaître ses prédécesseurs. Ce guide retrace l’évolution en trois générations — locale, centralisée, distribuée — pour que vous compreniez les choix de conception de Git.

Ce que vous allez apprendre

Les 3 générations de systèmes de contrôle de version
Pourquoi chaque génération a corrigé les limites de la précédente
Pourquoi Git a gagné face à Subversion, CVS et Mercurial

Qu’est-ce que le contrôle de version ?

Le contrôle de version (VCS — Version Control System) est un système qui enregistre les modifications apportées à un ensemble de fichiers au fil du temps. Il permet de :

Revenir à une version précédente d’un fichier ou du projet entier
Comparer les modifications entre deux versions
Savoir qui a modifié quoi et quand
Travailler à plusieurs sur le même projet sans se marcher dessus

Génération 1 : les VCS locaux

Les premiers outils de versioning fonctionnaient sur un seul ordinateur. Le plus connu est RCS (Revision Control System, 1982).

Le principe : RCS stocke les différences (patches) entre chaque version dans un fichier spécial sur votre disque. Pour reconstituer une version, il rejoue les patches les uns après les autres.

Avantage	Limite
Simple à utiliser	Un seul développeur à la fois
Pas de réseau nécessaire	Aucune sauvegarde distante
Rapide (tout est local)	Pas de collaboration possible

Le problème fondamental : impossible de travailler à plusieurs. Si votre disque dur lâche, tout l’historique est perdu.

Génération 2 : les VCS centralisés

Pour permettre la collaboration, les VCS centralisés placent l’historique sur un serveur unique. Les développeurs récupèrent la dernière version, travaillent, puis renvoient leurs modifications au serveur.

Les outils emblématiques de cette génération :

CVS (Concurrent Versions System, 1990)
Subversion / SVN (2000) — successeur de CVS
Perforce (1995) — commercial, encore utilisé dans le jeu vidéo

Avantage	Limite
Collaboration possible	Serveur = point unique de panne
Administration centralisée	Pas de travail hors-ligne
Permissions par dossier	Opérations lentes (réseau requis)

Workflow typique en SVN

Développeur A                Serveur SVN              Développeur B
     │                           │                          │
     ├── svn checkout ──────────▶│                          │
     │                           │◀──── svn checkout ───────┤
     │   (travaille)             │            (travaille)   │
     ├── svn commit ────────────▶│                          │
     │                           │◀──── svn commit ─────────┤
     │                           │   (conflit possible !)   │

Le point clé : chaque opération passe par le réseau. Sans connexion au serveur, pas de commit, pas d’historique, pas de diff.

Génération 3 : les VCS distribués

Les VCS distribués résolvent le problème du serveur central en donnant à chaque développeur une copie complète de l’historique. Pas seulement la dernière version — tout l’historique depuis le début du projet.

Les outils de cette génération :

Git (2005) — créé par Linus Torvalds pour Linux
Mercurial (2005) — similaire à Git, syntaxe plus simple
Bazaar (2005) — soutenu par Canonical (Ubuntu)

Avantage	Détail
Travail hors-ligne complet	Chaque copie contient tout l’historique
Pas de point unique de panne	Si un serveur tombe, n’importe quel clone peut le restaurer
Opérations ultra-rapides	commit, log, diff, branch — tout est local
Branches légères	Créer une branche ne coûte presque rien
Workflows flexibles	Centralisé, fork, dictator, pull-request… tout est possible

Pourquoi Git a gagné

Git a été créé en 2005 par Linus Torvalds pour gérer le code source du noyau Linux, après un conflit de licence avec BitKeeper (un VCS propriétaire). Les objectifs de conception étaient clairs :

Vitesse : les opérations courantes doivent être instantanées
Intégrité : chaque fichier est vérifié par un hash SHA
Support des branches : créer et fusionner des branches doit être simple et rapide
Distribution : chaque développeur a une copie complète

En 2026, Git domine très largement le marché. Selon le Stack Overflow Developer Survey, plus de 95 % des développeurs utilisent Git. Mercurial et Bazaar sont devenus marginaux.

Comparatif des 3 générations

Critère	Local (RCS)	Centralisé (SVN)	Distribué (Git)
Collaboration	Non	Oui	Oui
Travail hors-ligne	Oui	Non	Oui
Point unique de panne	Oui (disque local)	Oui (serveur)	Non
Vitesse des opérations	Rapide	Lent (réseau)	Rapide (local)
Branches	Inexistant	Lourdes (copie complète)	Légères (pointeur)
Intégrité des données	Non	Non	SHA sur chaque objet

Dépannage : questions fréquentes

Question	Réponse
Mon entreprise utilise encore SVN, que faire ?	Git peut importer un historique SVN avec `git svn clone`. La migration est bien documentée.
Mercurial est-il mort ?	Quasiment. Facebook l’utilisait mais a migré vers un fork interne. Le développement est au ralenti.
Git et GitHub, c’est la même chose ?	Non. Git est l’outil en ligne de commande. GitHub est une plateforme web qui héberge des dépôts Git.

À retenir

Le contrôle de version enregistre l’évolution de vos fichiers dans le temps
Les VCS locaux (RCS) ne permettent pas la collaboration
Les VCS centralisés (SVN) dépendent d’un serveur unique
Les VCS distribués (Git) donnent à chaque développeur une copie complète — rapide, résilient, flexible
Git domine le marché depuis 2010+ grâce à sa vitesse, ses branches légères et son modèle distribué

Prochaines étapes

Le modèle Git : snapshots et SHA Comprenez comment Git stocke réellement vos données.

Installer et configurer Git Passez à la pratique : installez Git sur votre système.

Présentation du chapitre Git Retrouvez le parcours complet et choisissez votre niveau.