« On utilise SVN, mais maintenant qu’il y a Git, on pense à basculer d’ici quelques mois ».
Cette phrase, vous l’avez peut-être prononcée, et vous ne seriez pas le seul. SVN, on connaît, il est utilisé depuis toujours, il fonctionne bien, mais tout le monde parle de Git, surtout les jeunes diplômés et les projets open source sur le web. A priori Git c’est mieux, enfin c’est ce qu’on vous dit, mais ça a l’air plus compliqué que SVN, et vous n’êtes pas certain des avantages dont vos projets bénéficieraient en l’adoptant.
Si vous vous reconnaissez dans ces phrases, rassurez-vous, vous êtes dans la majorité, et ce billet est fait pour vous !
SVN = Ancien, centralisé, simple
Git = Récent, décentralisé, compliqué
Ces deux phrases lapidaires résument nombre d’articles sur le sujet, et bien entendu la réalité est plus subtile que cela. Commençons par ancien / récent. SVN est en effet un vieux compagnon de route, fiable et simple. Git a été créé en 2005 par Linus Torvalds pour gérer le code du kernel de Linux, il va donc bientôt souffler ses 10 bougies. 10 ans vraiment? mais on n’en entend parler que depuis 3 ans !
En effet, sa popularité est récente, et il s’est maintenant imposé comme la nouvelle solution pour deux raisons : d’abord, le profil des équipes IT a évolué, et le principe de décentralisation du dépôt présente désormais une réelle utilité. Ensuite, l’ergonomie des outils gravitant autour de Git s’est nettement améliorée, gommant totalement la barrière à l’entrée qui repoussait la plupart des utilisateurs.
Les vertus de l’archivage décentralisé
On peut distinguer deux grandes familles de technologies d’archivage: les dépôts centralisés dont le porte-drapeau est SVN, et les dépôts décentralisés dont le plus connu est Git.
SVN propose un serveur central où l’ensemble des données sont stockées. Les utilisateurs récupèrent une copie locale des fichiers qu’ils souhaitent modifier sur leur machine, avant de les redéposer sur le serveur central. C’est un modèle comparable à Dropbox par exemple, dont les vertus sont la simplicité et la robustesse.
Git propose quant à lui un mécanisme pouvant se passer d’un serveur central, où chaque utilisateur dispose sur son disque dur de l’ensemble de l’historique du projet, et où par conséquent chaque collaborateur est un serveur potentiel. Les données sont synchronisées entre utilisateurs par une mécanique de fusion de branches. Ce principe peut s’avérer utile dans beaucoup de situations, notamment à chaque fois qu’un utilisateur ne peut pas se connecter à son serveur central.
Prenons l’exemple d’un développeur utilisant SVN qui part en déplacement pendant 1 semaine. Il travaille dans le train, puis dans son hôtel au Wifi capricieux et mal sécurisé, et pendant tout ce temps il lui est impossible de se connecter sur son serveur central SVN, et donc d’archiver son code. Avec Git, il peut archiver son travail sur son disque dur (base locale), et repartir sur le tronc commun une fois une bonne connexion retrouvée.
A quoi cela sert-il ? Il y a de nombreux avantages, dont :
- Labelliser chaque modification dans une « change list » dédiée : rien de pire que de faire un énorme archivage (SVN commit) contenant des dizaines de fichiers modifiés pour des tâches différentes. Chaque tâche devrait avoir son propre archivage labellisé correctement avec seulement les fichiers concernés par la tâche en question. C’est une question de cohérence du nommage des modifications, mais également de gestion de projet : Comment faire si le chef de projet décide de n’intégrer qu’une seule des tâches et de garder l’autre pour la version suivante ? Ou comment dichotomiser correctement si la change-list introduit un bug ?
- Comparer des versions locales : « Ça marchait hier, mais ça ne marche plus aujourd’hui, qu’est-ce que j’ai changé ? ». Impossible de répondre à cette question si vous utilisez SVN loin de votre serveur central. Avec Git, vos archivages locaux réguliers vous permettront de retracer l’historique des modifications de chaque fichier.
- Collaborer avec un autre développeur sur place: inutile d’avoir accès au serveur central pour partager sa branche, ou réintégrer les modifications d’un tiers.
Dans les faits, la plupart des projets Git disposent d’un serveur central qui contient la version principale du code (le « trunk » de SVN). Mais ce serveur n’est qu’un utilisateur comme un autre du point de vue Git. Ainsi, si le serveur tombe en panne, n’importe quel utilisateur peut devenir temporairement le serveur de référence. En somme, l’archivage décentralisé de Git permet aux équipes plus de flexibilité et de mobilité.
On comprend alors mieux pourquoi le monde de l’Open Source a poussé Git en avant : ce sont des équipes réparties dans le monde entier et qui n’ont souvent pas de locaux propres.
Compliqué ?
Malheureusement, tous ces avantages ont une contrepartie : Git est immensément plus difficile à comprendre et à manœuvrer que SVN. Ces deux technologies d’archivage disposent d’une série d’outils et « wrappers » qui en simplifient l’utilisation, mais c’est encore SVN qui dispose de la meilleure bibliothèque d’outils gratuits, dont le célèbre Tortoise. Git dispose également d’une suite d’outils gratuits, mais qui restent limités.
Il n’en fallait pas plus pour que fleurissent des solutions payantes pour Git, dont les plus connues sont Github et Stash. Ces produits ont réussi à offrir des interfaces aussi simples à manipuler que SVN, tout en exploitant les possibilités avancées de Git.
Boostez la collaboration
Git est plus rapide que ses concurrents, il est plus flexible grâce à son principe de décentralisation, et sa base de données est généralement plus petite que les autres solutions. C’est intéressant, mais peut-être pas assez pour prendre la décision de franchir le pas. Et si Git améliorait aussi la collaboration au sein de vos équipes de développement ?
Le travail par branches permet de passer d’une tâche à l’autre sans interférence. Prenons un développeur qui travaille depuis 5 jours sur une fonctionnalité. En urgence, vous lui demandez d’aider un autre développeur à résoudre un problème. Si vous travaillez avec SVN, l’archivage du travail en cours ainsi que la récupération du travail du second développeur ne vont pas se faire simplement. En revanche, avec Git c’est une affaire de quelques secondes : le développeur archive son travail sur sa branche, et récupère la branche de son collègue pour travailler directement dessus. Quand il aura terminé, il reviendra sur sa branche sans avoir perdu ses modifications. Le système de Git rend la création et la manipulation de branches très facile et extrêmement rapide, les développeurs n’hésitent donc plus à utiliser leur puissance.
Quand on parle collaboration dans une équipe de développement IT, un des sujets inévitables est la code review. Son principe est d’exiger qu’un pair ou un manager relise les modifications apportées au code par un développeur avant de les intégrer à la branche principale. Il s’agit donc d’une relecture par un ou plusieurs tiers pour validation. Cette pratique est parfois difficile à mettre en place, notamment pour deux raisons : d’abord, il faut que tous les membres de l’équipe adoptent le réflexe de faire relire leur travail, et ensuite il faut trouver un collaborateur qui a du temps libre au moment où l’on veut être relu.
Pour faire face à ces difficultés, des produits comme GitHub et Stash ont mis en place un système de « pull request », dont le principe est le suivant : le développeur qui veut soumettre son code aux autres le met en ligne, à disposition de ses collaborateurs. Ces derniers reçoivent alors une notification, et peuvent quand ils le souhaitent lire le code et l’annoter afin de faire des retours au développeur, et in-fine valider ou rejeter les modifications. Ce principe systématise la revue de code puisqu’il devient impossible d’archiver du code sur la branche principale sans passer par le mécanisme d’approbation par un tiers d’une pull request. D’autre part, le fait que la modification soit consultable et annotable en ligne permet aux collaborateurs de relire et valider le code même s’ils sont géographiquement loin ou pas disponibles immédiatement.
Stash
Quand on parle de logiciels permettant d’améliorer la collaboration, on pense immédiatement à Atlassian qui est la référence en la matière. Très impliqué dans la promotion de Git, Atlassian a créé Stash, qui est le meilleur outil d’interfaçage de Git sur le marché.
Comme tous les produits Atlassian, Stash offre une interaction explicite avec les autres produits de la suite (JIRA, Bamboo, etc.) mais il se détache vraiment de la concurrence en termes de simplicité d’utilisation et de ses fonctionnalités avancées. Notamment, il permet d’aller très loin dans les mécaniques de revue de code.
En effet, chacun des pairs peut voir les modifications apportées à chaque fichier et les commenter dans un forum ad-hoc afin d’en débattre avec l’auteur et les autres développeurs. On peut exiger qu’une modification soit approuvée par un ou plusieurs collaborateurs spécifiques pour que le système autorise son intégration dans le tronc commun. Stash propose même une fonctionnalité de suggestion automatique du meilleur collaborateur pour faire la revue de code (en se basant sur qui a écrit les lignes qui ont été modifiées).
Conclusion
Le monde des dépôts de code est longtemps resté très calme, il y a eu CVS, puis SVN, et enfin Git mais désormais les choses s’accélèrent et beaucoup de solutions hybrides fleurissent (Bazaar, git-svn, etc.) et brouillent un peu plus les pistes en proposant de reprendre le meilleur des deux mondes.
Cependant, la progression du nomadisme, des équipes décentralisées, et la culture des jeunes diplômés donnent aujourd’hui l’avantage aux technologies de type Git. Si vous voulez vous lancer, Stash est aujourd’hui le meilleur outil pour faciliter la transition vers Git et en exploiter pleinement le potentiel.
Pour aller plus loin, visionnez notre webinar git+stash:
[youtube_sc url=”https://www.youtube.com/watch?v=HAZMXYILXx0&list=UUFuQ8ynd16nOPo2WoKp8k9w” title=”Valiantys%20Weninar%20Git%20+%20Stash”]
