Système de contrôle de version

Un système de contrôle de version (VCS) enregistre les modifications apportées à un ensemble de fichiers au fil du temps, afin de pouvoir rappeler n'importe quelle version spécifique ultérieurement. Cette page explique ce qu'est le contrôle de version, pourquoi les équipes de développement en dépendent, les trois familles d'outils VCS (local, centralisé et distribué), ainsi que les avantages concrets que chacun apporte. C'est le fondement conceptuel de tout le reste de ce livre — une fois que vous comprenez pourquoi le contrôle de version existe, des commandes comme git init, git commit et git branch prennent beaucoup plus de sens.

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

Le contrôle de version est un système qui enregistre les modifications apportées au code source (ou à tout ensemble de fichiers) afin qu'une équipe puisse gérer l'évolution de ce code au fil du temps. Au lieu d'écraser des fichiers et de perdre l'état précédent, le système stocke chaque modification significative sous forme de révision à laquelle vous pouvez revenir.

Concrètement, le contrôle de version vous permet de :

• Voyager dans le temps — restaurer n'importe quelle version antérieure d'un fichier ou de l'ensemble du projet.
• Voir qui a modifié quoi, et pourquoi — chaque révision porte le nom de son auteur, une date et un message.
• Travailler en parallèle — séparer des lignes de travail indépendantes dans des branches et les combiner plus tard avec une fusion.
• Comparer des versions — visualiser les différences exactes entre deux points de l'historique grâce à un diff.

Pourquoi c'est important

Le contrôle de version est indispensable dès lors que plusieurs personnes — ou plusieurs machines, ou même simplement vous-même dans le temps — touchent à une base de code. Il permet à plusieurs développeurs de travailler séparément sans écraser le travail des autres, puis d'intégrer ces modifications de manière traçable. Il transforme également "j'ai cassé quelque chose et je ne sais pas quoi" en une question à laquelle vous pouvez répondre : vous pouvez identifier le changement exact qui a introduit un bug et annuler uniquement ce changement.

Même sur un projet solo, le contrôle de version vous offre un filet de sécurité. Vous pouvez expérimenter librement, sachant que chaque état fonctionnel est sauvegardé et récupérable.

Systèmes de contrôle de version (VCS)

Un système de contrôle de version (VCS) — également appelé gestion du code source (SCM) ou système de contrôle de révision (RCS) — est l'outil logiciel qui met en œuvre le contrôle de version : il suit les modifications, stocke l'historique et coordonne la collaboration.

Les trois types de systèmes de contrôle de version

Historiquement, les outils VCS se répartissent en trois familles, chacune résolvant un problème laissé par la précédente.

1. Les systèmes de contrôle de version locaux

Un VCS local conserve l'intégralité de l'historique dans une simple base de données sur une seule machine. Il a été créé pour prévenir les erreurs courantes telles que la modification du mauvais fichier ou la perte d'une version précédente lors de la copie manuelle de répertoires. L'un des outils locaux les plus populaires est RCS (Revision Control System), encore distribué aujourd'hui. RCS stocke des ensembles de correctifs (les différences entre les versions) afin de pouvoir recréer n'importe quel fichier tel qu'il se présentait à n'importe quel moment.

La limitation est évidente : l'historique réside sur un seul ordinateur, ce qui n'offre aucune collaboration réelle et aucune protection en cas de défaillance du disque.

2. Les systèmes de contrôle de version centralisés

Un VCS centralisé (CVCS) stocke tous les fichiers versionnés sur un serveur central unique, et les clients « extraient » des fichiers depuis cet emplacement unique. Cela a résolu le problème de collaboration : tout le monde pouvait voir, dans une certaine mesure, ce que les autres faisaient, et les administrateurs disposaient d'un point de contrôle unique. Pendant de nombreuses années, c'était la norme. Les exemples courants sont CVS, Subversion (SVN) et Perforce.

La contrepartie est le point de défaillance unique. Si le serveur central tombe en panne, personne ne peut valider ou collaborer ; si son disque est perdu sans sauvegarde, toute l'histoire du projet peut être perdue avec lui.

3. Les systèmes de contrôle de version distribués

Dans un VCS distribué (DVCS), chaque client ne se contente pas d'extraire les derniers fichiers — il effectue une copie miroir complète du dépôt, y compris l'historique complet. Si le serveur tombe en panne, le clone de n'importe quel client peut être poussé pour le restaurer. Cela rend également la plupart des opérations rapides et utilisables hors ligne, car l'historique complet est local. Les exemples incluent Git, Mercurial, Bazaar et Darcs.

C'est le modèle utilisé par Git, et c'est pourquoi vous pouvez valider, créer des branches, afficher l'historique et faire des diffs sans aucune connexion réseau. Le reste de ce livre couvre Git en profondeur — commencez par Qu'est-ce que Git ? et l'installation de Git.

Avantages des systèmes de contrôle de version

Les principaux avantages d'un VCS sont :

1. Historique des modifications à long terme. Chaque création, modification et suppression d'un fichier est enregistrée tout au long de la vie du projet. Cela vous permet de revenir à une version précédente pour analyser les bugs et résoudre les problèmes.
2. Branches et fusions. Les branches permettent aux développeurs de travailler indépendamment sans interférer les uns avec les autres. La fusion rassemble ce travail et met en évidence les conflits pour qu'ils puissent être résolus délibérément.
3. Traçabilité. Vous pouvez retracer chaque modification, l'annoter avec un message décrivant son but, et la connecter aux outils de gestion de projet et de suivi des bugs.

Le contrôle de version en pratique

Vous n'avez pas besoin d'un serveur ni d'une équipe pour voir le contrôle de version fonctionner — Git suit l'historique directement sur votre propre machine. Les commandes ci-dessous s'exécutent entièrement en local : elles créent un dépôt, enregistrent deux versions d'un fichier, puis demandent à Git l'historique de ce fichier. Essayez-les dans un terminal après avoir installé Git.

# Create a fresh project and turn it into a Git repository
mkdir vcs-demo && cd vcs-demo
git init -q

# Tell Git who is making the changes (required for a commit)
git config user.email "[email protected]"
git config user.name "You"

# Record the first version
echo "line one" > notes.txt
git add notes.txt
git commit -q -m "Add notes.txt"

# Change the file and record a second version
echo "line two" >> notes.txt
git commit -q -am "Add a second line"

# Ask version control for the history of this file
git log --oneline

La sortie de git log --oneline liste deux révisions, la plus récente en premier — chacune avec un court hash de commit et le message que vous avez écrit :

3f8a1c2 Add a second line
9b2e4d7 Add notes.txt

(Vos hashes seront différents, car ils sont calculés à partir du contenu et de l'horodatage.) Cet historique est au cœur du contrôle de version : chaque version est sauvegardée, étiquetée et récupérable. Pour aller plus loin, consultez git log et git commit.

Pratique