Introduction

Cette introduction est inspirée des pages suivantes et de ma propre expérience :

Pourquoi un VCS ?

Garder des traces

Un gestionnaire de versions permet de garder des traces précises et complètes des modifications apportées tout au long du développement d'un projet. Cela est utile qu'on soit seul ou à plusieurs. Sans VCS, on ne peut pas savoir instantanément si une fonctionnalité est en cours de développement ou bien finie. On ne peut pas savoir non plus qui est la dernière personne qui a modifié un fichier et les raisons de ses modifications. Des milliers de cas concrets illustrent les bienfaits de garder un historique de ses modifications. Cette tâche devient naturelle et facile avec un VCS.

Le travail à plusieurs

Prenons un cas concret très simple : Alice et Bob sont deux développeurs qui n'utilisent pas de système de gestion de version. Ils veulent produire ensemble un document texte.

Les deux scenarios classiques sont :

Premier scenario : pas d'organisation

Alice commence à écrire le document qu'elle envoie par mail à Bob au bout d'une semaine de rédaction. Bob lit le document qu'il a reçu, voit qu'elle a commis quelques fautes d'orthographe, les corrige et ajoute un chapitre au milieu du document. Pendant ce temps là, Alice a continué la rédaction de son côté. Bob envoie sa version du document à Alice. Si Alice veut être sûre de bien fusionner les deux documents, elle doit les comparer ligne par ligne pour récupérer les éventuelles modifications que Bob a fait puisqu'elle ne sait pas où se trouvent ces modifications. Elle devra faire ce travail lourd et dangereux à chaque fois qu'ils échangeront des versions du document sur lesquelles ils ont travaillé en même temps. Ces problèmes sont complètement gérés par les VCS, de la transmission du document, à la fusion automatique en passant par la gestion des modifications conflictuelles...

Second scénario : un peu d'organisation

Pour se communiquer le document, ils accèdent à un espace FTP partagé. Par précaution, ils décident de rédiger un chapitre différent pour éviter d'écrire deux fois la même chose ou de se perdre dans des techniques d'organisation trop compliquées. Dans un monde idéal, chacun ne modifient que le chapitre qui lui est alloué, comme prévu. Une fois qu'Alice et Bob ont terminé leurs chapitres respectifs, ils déposent leur version du document sur l'espace FTP avec un nom différent (document_alice.txt et document_bob.txt par exemple). Ensuite l'un d'entre eux, Alice par exemple, doit fusionner les deux versions du document pour obtenir le document global, fruit de leurs deux rédactions. Elle ouvre les deux documents, fait un gros copier-coller et sauve le nouveau document. Elle devra faire cette opération à chaque fois que l'un d'entre eux modifie son chapitre à nouveau. Si d'autres personnes se greffent au projet, elle devra faire cette fusion manuelle à chaque modification d'un des rédacteurs.

S'ils avaient utilisé un VCS, la transmission du travail et la fusion des documents auraient été automatiques et instantanées, et surtout asynchrones.

Maintenant imaginons qu'Alice trouve une faute d'orthographe dans le chapitre de Bob et qu'elle la corrige dans le document fusionné qu'elle produit. La prochaine fois qu'elle fusionnera les documents, si Bob n'a pas appliqué la correction d'Alice sur son document de travail (document_bob.txt) contenant son chapitre uniquement, Alice va écraser sa correction avec la version fausse de Bob.

S'il avaient utilisé un VCS, le système aurait signalé un conflit entre les versions d'Alice et Bob sur chaque modification posant problème. Le VCS aurait aussi permis à l'un d'entre eux de choisir, pour chaque modification conflictuelle, de choisir celle qui va réellement être appliquée au projet.

Ces deux scénarios sont des petits exemples de confusion dans le travail à plusieurs sans outils. On peut en imaginer des milliers d'autres possibles et probables.

En résumé un des objectifs principaux des VCS est de structurer et simplifier les interactions entre les membres d'un projet de développement à plusieurs.

Sauvegarde et fiabilité

La plupart des VCS permettent ou nécessitent la création de plusieurs copies du projet. De cette manière il est beaucoup plus difficile de perdre le projet ou une partie du projet.

Grace à l'historisation des modifications, même à la suite d'une suppression involontaire, on peut naturellement retrouver tout ce qui a existé par le passé.

Qu est ce qu un VCS ?

Un gestionnaire de version est un logiciel dont la fonction principale est de garder un historique des modifications d'un ou plusieurs fichiers. Grace à cette historisation des modifications, il est très simple de naviguer dans les différents états qu'ont pu avoir les fichiers auparavant, annuler des modifications, identifier l'auteur d'une modification etc...

La plupart des gestionnaires de version permettent aussi un transfert simple des modifications d'un développeur à l'autre.

Il en existe différents types, que nous allons décrire ensuite, qui offrent plus ou moins de fonctionnalités additionnelles et de souplesse pour la gestion à plusieurs.

Qu est ce qu une version ?

Une version est un ensemble de modifications faites par une personne entre deux dates précises. On peut aussi dire, une version regroupe tous les changements qu'une personne a fait depuis la version précédente.

Le terme souvent employé pour dire "ensemble de modifications" est "changeset". Du point de vue d'un VCS, une modification est une ligne d'un des fichiers versionnés qui diffère de celle de la version précédente.

Il est très conseillé de commenter ses versions pour identifier plus rapidement quel était l'objet de la modification. Il est aussi très conseillé de faire des versions atomiques, c'est à dire qui ne concernent qu'un sujet et n'ont qu'un but restreint à ce sujet. Une version devrait concerner entre 1 et 200 lignes.

Types de VCS

Centralisé

On appelle aussi ce type de VCS : client-serveur.

Subversion (SVN) et CVS sont des gestionnaires de version centralisés. Un projet est matérialisé sous deux formes :

  • Le dépôt central
  • Les copies de travail

Le dépôt central n'est pas manipulable par les développeurs. Premièrement ils doivent s'adresser au dépôt central pour demander une copie de travail qui est en fait la copie de tous les fichiers du projet à la dernière version produite. Après avoir apporté des modifications, un développeur (appelons le Bob) doit produire une version (commit). Cette opération va communiquer les dernières modifications au dépôt central pour créer une nouvelle version. Si un autre développeur (Alice) a créé entre-temps une nouvelle version, la version de Bob est refusée par le dépôt central qui lui demande alors de mettre à jour sa copie de travail avant de faire une version. Bob met à jour (update) sa copie de travail.

Si les modifications d'Alice ne sont pas conflictuelles avec le travail de Bob, la mise à jour réussi et Bob peut ensuite effectuer son commit avec succès.

Si un conflit survient au moment de son update, Bob doit le régler localement c'est à dire choisir pour chaque modification conflictuelle s'il préfère la sienne ou celle du dépôt central.

Commandes essentielles d'un VCS centralisé :

  • checkout : crée une copie de travail à partir du dépôt central
  • update : met à jour la copie de travail à partir du dépôt central
  • commit : essaie de créer une version et de la transmettre au dépôt central

Distribué (DVCS)

Les DVCS les plus connus sont : Git, Mercurial (hg), Darcs, Bazaar.

La différence de conception entre les VCS centralisés et distribués est simple :

Toute copie de travail est autonome et contient tout l'historique. Cela permet de séparer la création/manipulation de versions et la communication de versions.

Cette différence parait petite mais elle permet un gain de souplesse et de fonctionnalités énorme :

  • On peut créer une version sans la transmettre à un dépôt et donc travailler OFFLINE
  • On n'a plus de différence entre copie de travail et dépôt local. Chaque copie de travail est une copie complète du projet et de son historique. On augmente donc le nombre de sauvegardes.
  • On peut échanger des versions avec plusieurs dépôts distants
  • On n'est plus obligé de centraliser donc :
    • On peut forker instantanément
    • On est libre de s'organiser comme on le souhaite
  • On peut ANNULER des modifications
  • On peut faire des branches
  • On peut naviguer rapidement entre les versions
  • ...

En résumé on est libre de faire ce que l'on veut sur sa copie de travail (modifier l'historique, manipuler les branches, tagger...). On peut envoyer/recevoir des versions vers/depuis d'autres copie de travail locales ou distantes modulo restrictions d'accès.

Commandes principales :

  • clone : duplique un dépôt distant
  • pull : récupère (tire) les nouvelles versions provenant d'un dépôt distant
  • push : envoie (pousse) les nouvelles versions locales vers un dépôt distant
  • commit : crée une version localement

Pourquoi les DVCS ?

Les VCS centralisés ont montré leurs limites dans plusieurs domaines :

  • Souplesse d'organisation : Avec un VCS centralisé, tout utilisateur autorisé à commiter peut aussi résoudre un conflit donc éventuellement supprimer les modifications d'autrui sans contrôle. Avec une architecture décentralisée on peut imaginer différents rôles comme le chef de projet qui est le seul à pouvoir pousser sur le dépôt officiel du projet. Les développeurs peuvent tous avoir un dépôt public sur lequel ils peuvent pousser. Le chef de projet peut ainsi décider s'il prend ou non les modifications de chacun. Une fois des modifications apportées au dépôt officiel, tout le monde peut le puller et se maintenir à jour par rapport aux décisions du chef de projet. Si un développeur décide de garder ses modifications qui ont été refusées par le chef de projet, il continue à puller le dépôt officiel sans effacer ses modifications personnelles.

  • Gestion des branches : Dans Subversion, la gestion d'une branche est fastidieuse et nécessite la duplication des fichiers. Avec les DVCS, celle ci devient plus simple et locale.

  • Performance : Avec Subversion, toute opération qui nécessite une consultation de l'historique doit communiquer avec le dépôt central. Cette communication génère un temps de latence qui peut être important en fonction de la connexion réseau disponible. Avec un DVCS, on interroge l'historique local, ce qui est plus rapide et nous dispense du besoin d'être connecté.

  • Richesse des outils proposés : Il existe énormément d'outils liés à Git et Mercurial pour voir l'historique, faire des statistiques, héberger des dépôts, gérer les branches...

Pourquoi GIT et pas un autre DVCS ?

Git est le plus populaire, le plus fourni en documentation, le plus fourni en outils, le plus performant des DVCS.

Voila quelques pages qui abordent les différences entre les DVCS :