Les systèmes de gestion de version centralisés
Comme nous venons de le voir, le manuel Linux précise aussi que Git est un système de gestion de version « distribué » (parfois dit aussi « décentralisé »). Pour comprendre cette distinction, il faut faire une petite incursion dans l'histoire des VCS. En effet, les premiers gestionnaires de version introduits dans les années 1990 comme CVS (Concurrent Version System) ou Subversion permettaient de stocker les fichiers et leurs versions sur un serveur qui jouait un rôle de point de dépôt centralisé.
En plus de dépendre d'un équipement sur le réseau, ces VCS stockaient deux types de fichiers :
- La version initiale d'un fichier
- Plusieurs fichiers (versions) contentant les différences avec le fichier d'origine après chaque modification.
I. VCS : une approche axée sur la différence
Cette approche axée sur le delta ou « différence » (delta-based version control) peut être illustrée ainsi :
Dans les VCS centralisés, l’information est stockée comme un ensemble de fichiers initiaux (version 1) et des fichiers contenant les différences par rapport aux premiers (versions subséquentes). Le principal inconvénient que présente cette approche apparaît lorsqu'on souhaite restaurer une version antérieure d'un fichier. Pour effectuer cette tâche, le VCS doit reconstruire le fichier désiré en appliquant tous les changements accumulés depuis la version initiale. Ce processus peut être très long et il suppose, bien sûr, que seule la version centralisée soit intègre. Ceci met en lumière deux autres inconvénients des VCS centralisés :
- Les utilisateurs sont dépendants d’une connexion réseau pour mettre à jour leur dépôt (repository) ou accéder à l’historique des modifications : ils n'ont pas l'entièreté du dépôt sur leur poste de travail.
- Le serveur utilisé comme point de dépôt est un point de défaillance unique (single point of failure).
Ces derniers aspects permettent de mieux comprendre pourquoi Linus Torvalds souhaitait créer un outil performant qui aurait la particularité de ne pas dépendre d'un modèle centralisé. Mais, ce qui était sans doute l'idée la plus ingénieuse tient au fait que Git est un VCS distribué, c'est-à-dire qu'il permet d'avoir l'entièreté d'un même dépôt de code source localement sur un ou plusieurs ordinateurs.
Contrairement aux systèmes de gestion de version distribués que nous définirons sous peu, les VCS centralisés limitent les utilisateurs aux deux opérations suivantes :
- Mettre à jour (synchroniser) leur copie de travail locale à partir du dépôt centralisé.
- Enregistrer (faire un commit) des modifications apportées à leur copie de travail locale pour les envoyer sur le dépôt centralisé.
Nous reviendrons plus loin sur la notion de « commit » qui réfère à l'enregistrement de l'état d'un fichier ou d'un ensemble de fichiers dans un système de gestion de versions.
II. Le workflow d'un système de gestion de version centralisé
Le schéma suivant illustre le workflow des utilisateurs d'un gestionnaire de version centralisé :
