Évolution des systèmes de gestion de versions

Je te montre maintenant avec quelques animations la manière dont les outils de gestion de versions ont évolués dans le temps, pour que tu comprennes les inconvénients de certains, et surtout les avantages des nouveaux. Et quand je dis nouveau, c’est parce que Git n’est pas seul, il y en a d’autre comme Mercurial par exemple.

Au départ on faisait de bonnes vieilles sauvegardes locales à la mano, dans des répertoires horodatés, éventuellement compressés quand on était sérieux.

C’est là que les premiers systèmes de gestion de versions sont arrivés, comme CVS, ClearCase, Subversion, en nous proposant de déporter nos sauvegardes et de permettre un partage plus facile.

Cette approche avait un tout petit défaut, ça nécessitait une connexion réseau pour travailler avec le dépôt central. Quand je dis « tout petit », je suis ironique, parce que ça veut dire que quand il n’y a plus de réseau, on ne peux plus travailler avec l’équipe. Donc ça chiffre vite. Perso, j’ai éprouvé ça en entreprise, et, au-delà de la perte d’argent que ça représente pour la boite, le fait d’avoir une pause obligatoire à durée indéterminée pour toute l’équipe, c’est pas folichon !

Du coup c’est en partant de ce constat que les systèmes distribués ont été créés. Leur but est de nous libérer de la contrainte du réseau, mais pas que, puisqu’ils nous libèrent aussi de la contrainte du serveur en intégrant localement les versions. En gros, on se retrouve avec l’intégralité des versions du projets sur les différentes machines de l’équipe, ce qui fait qu’on peut tout à fait travailler si le serveur central tombe, ou en remonter un vite fait, même s’il ne faisait pas l’objet de sauvegardes régulières. 

Là encore j’ai un retour d’expérience à te faire puisque j’ai vécu le crash d’un serveur SVN, et vu qu’il n'était pas sauvegardé, impossible de recréer l’historique du projet, on est reparti d’un historique démarrant au jour du crash.

Si je rentre plus dans le détail, voici en quoi les systèmes de gestion de versions distribués sont mieux que les autres. 

Pour commencer, on a plus de criticité du serveur, et donc on a plus la nécessité d’y être connectés à tout instant. Ce qui veut dire que si le serveur brûle, tout le monde peut continuer de travailler localement, et on pourrait même travailler de machine à machine. Bon en vrai, si le serveur brûle, je pense que tu as d’autres priorités que de continuer à bosser sur ton projet, comme… sauver ta vie, ou éteindre le début d’incendie par exemple… bon après, c’est toi qui vois !

On peut aussi facilement remonter un serveur puisque l’intégralité des versions est conservée sur les différentes machines, donc on ne perd rien.

Enfin, on est tranquille si le réseau tombe puisque l’essentiel des opérations (c’est-à-dire toutes sauf le partage) se fait localement. Donc si le réseau de l’entreprise tombe : tu peux travailler de manière isolée sur ta machine et tu te synchroniseras quand le réseau sera revenu.

Il y a encore d’autres avantages qui découlent de cette architecture, à commencer par la rapidité des opérations liées à l’historique (commit, log, reset, etc.) puisqu’elles s’effectuent localement ! Note enfin que tout ce qui est produit localement n’a pas l’obligation d’être partagé. Tu peux donc effectuer du travail « privé » sans gêner tes collaborateurs et sans avoir besoin des droits de commit.

Les concepts clés de Git

Git peut sembler mystérieux, mais comprendre ses concepts fonda­mentaux rend son utilisation lumineuse !