Quelques avantages et défauts de Git

Voilà plusieurs semaines que nous sommes passés de SVN à Git au bureau et j’ai pensé qu’un petit point ici serait bien. En effet, j’ai remarqué qu’un certain nombre de développeurs avaient tendance à nous imiter : si on utilise telle bibliothèque, je découvre quelques semaines plus tard par hasard qu’elle suscite un intérêt soudain chez un certain nombre de visiteurs du site. De la même manière, j’ai appris récemment qu’il était probable que le site des zCorrecteurs passe à Git (attention, c’est une rumeur, je ne sais pas s’ils le feront ;o).

Cela réussit toutefois à m’inquiéter car, si je suis flatté de voir que l’on serve d’exemple pour certaines personnes, il ne faut pas le faire aveuglément. Aucun de nos choix n’est parfait, et il faut bien mesurer les conséquences de son acte avant de changer quelque chose d’aussi important qu’un système de versionnement.

Je voudrais donc ici apporter un oeil critique sur Git. Je souhaite mettre en exergue à la fois les points positifs et les points négatifs que l’on en retire. Bien entendu, tout ceci est extrêmement subjectif. Je sais que Git n’a pas été prévu pour fonctionner comme ceci ou comme cela, mais on en fait un usage bien particulier et je tiens à dire les avantages et défauts sur lesquels on est tombés.

Avantages

• Le premier avantage, qui a été la première raison de notre migration, c’est sa gestion des branches. On peut enfin travailler sur plusieurs projets en parallèle sans se marcher sur les pieds. Nous avons donc commencé à utiliser intensivement cette fonctionnalité, et une fois qu’on a compris le fonctionnement c’est un vrai régal. C’est simple, ça marche, et on n’a pas à copier tout le projet comme avec SVN pour créer une branche.
• L’interface console un poil plus évoluée que SVN. Ce sont des choses toutes simples, comme le fait qu’il fasse un « less » pour paginer automatiquement lorsqu’on affiche le log des commits. Ou la couleur, plutôt agréable, qu’il faut néanmoins activer au préalable.
• Les algorithmes de fusion (merge) : quand un fichier a été modifié par plusieurs personnes en même temps, Git sait s’adapter et choisir un algorithme qui fusionne intelligemment les lignes du fichier qui ont été modifiées. Si par hasard 2 personnes ont modifié en même temps la même ligne (cas rare, mais qui arrive), il y a un conflit et Git laisse des marques dans le fichier pour dire qui a modifié quoi, et vous invite à décider ce que vous gardez.
• La rapidité : lorsque vous vous mettez à jour, les données sont empaquetées, compressées, et les mises à jour sont fusionnées à la vitesse de la lumière, même s’il y a eu de très nombreuses modifications depuis la dernière fois. Cette rapidité m’étonne réellement à chaque fois.
• Contrairement à SVN, Git ne surveille pas les fichiers mais leur contenu. Cela permet de faire des choses qui auraient été impossibles autrement, comme savoir qu’une fonction a été déplacée d’un fichier à un autre.

Défauts

• La complexité : quoiqu’on en dise, ce n’est pas un outil à mettre entre les mains de n’importe qui. C’est fait par des développeurs pour des développeurs. SVN est vraiment facile à utiliser à côté. Cette impression est renforcée par le fait que les commandes ne sont pas intuitives. La même commande semble servir pour 2 choses très différentes (je pense à checkout, qui permet de changer de branche et de remettre à jour un fichier depuis le dernier commit). D’un point de vue du développeur, je suis persuadé que c’était logique et même élégant. Du point de vue de l’utilisateur, c’est une aberration. Voilà ce qui me fait dire que Git se soucie assez peu de la difficulté de prise en main. Il y avait une surcouche qui simplifiait un peu l’utilisation, mais je crois qu’elle a été abandonnée.
• Le portage sous Windows est plutôt nul. Il faut utiliser cygwin. Heureusement, le projet msysgit permet d’avoir un installeur tout-en-un, mais je rencontre personnellement quelques difficultés : parfois, il ne veut plus se connecter au serveur par SSH, et ce sans raison apparente. Plus moyen de faire un pull… à moins de réinstaller msysgit. De plus, l’interface console n’est pas courante sous Windows. On est loin d’un TortoiseSVN par exemple. Certes, il existe TortoiseGit, mais il nécessite msysgit pour fonctionner. Enfin, les merges sont sensiblement plus lents sous Windows quand même.
• Les retours à la ligne ont intérêt à être tous du même type (\n par exemple). En effet, si l’un de vos développeurs travaille avec un éditeur sous Windows qui est configuré pour créer des \r\n comme retours à la ligne, toutes les lignes d’un fichier seront considérées comme changées lorsqu’il l’éditera… d’où de nombreux conflits de merge. Là encore, c’est à mettre en liaison avec le fait que c’est plutôt fait pour être utilisé sous Linux. Si tout le monde a Linux, édite avec des \n, encode en UTF-8, alors oui, il n’y aura pas de problème. :D
• Le très grand nombre de commandes qui existent. On peut se contenter de quelques-unes, mais on en découvre toujours de nouvelles, pas forcément très faciles ni très safe à utiliser. Il faut donc se méfier de ce qu’on fait. C’est à mettre en relation avec la complexité. Comme tout outil Unix, ça fait ce qu’on lui dit, même si on ne sait pas bien ce qu’on fait et qu’on débute (on n’a pas vraiment perdu de travail depuis le début, mais on a failli).

Maintenant ça va mieux, mais il a fallu un temps d’adaptation et pas mal de pédagogie pour que tout le monde l’utilise comme il faut. Ca ne s’utilise pas comme SVN, ça ne ressemble pas à SVN, ce n’est pas SVN. Sachez-le si vous comptez migrer : vous en retirerez de réels bénéfices, mais il faut que votre équipe soit constituée de développeurs, de préférence sous Linux, qui apprennent vite et qui sont habitués aux commandes Unix.

Ces listes ne sont pas exhaustives, je pourrais les compléter à l’occasion. Je pense néanmoins avoir dit l’essentiel pour donner grosso modo mon avis sur le sujet. :o)