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)

18 Comment
  1. Salut,

    Au niveau des zCos, c’est pas vraiment un coup de tête, on (enfin surtout les zArchitectes) a bien parlé dans les forums privés, pour peser le pour et le contre. Ce qui nous a aussi décidé c’est que DJ Fox l’utilise régulièrement sur le SdZ et n’a donné que de bons retours par rapport à SVN. :)

    En tous cas si on l’installe effectivement bientôt, je reviendrais donner mon avis détaillé sur GIT. ;)

    @+

  2. Haha en effet j’en connais qui est bien renseigné. :-° Personnellement même si je reconnais que SVN est super pour un débutant et s’initier aux SCM, à part ça, on atteint vite les limites. Actuellement on doit avoir 3 projets en cours, bah sans branches en foutant tout dans le trunk bonjour les passages en production non désirés et tout ce genre de choses. ^^ Vraiment pas cool et lourde la gestion des branches à mon avis.

    Bon à part ça, en vue d’un changement de SCM, j’ai étudié pendant quelques temps Bazaar, Mercurial et Git. J’ai dans un premier temps été plutôt séduit par Bazaar, sa richesse de plugins, et les fonctionnalités assez intéressantes offertes (en particulier bzr-upload pour passer envoyer le contenu du dépôt sur un serveur FTP). Mais au final, il apparait qu’il est très très lent, trop lent. Après, j’étais assez tenté par Mercurial qui cache une partie de la complexité de Git avec des concepts plus courants (je pense par exemple aux numéros de versions qui en effraient plus d’un). Mais bon DJ Fox étant au final assez habitué à Git, il ne souhaitait pas se mettre à un autre SCM, et semblait particulièrement conquis par Git, donc bon on va sans doute lui faire confiance et voir ce que ça donne pour nous. :)

    Bon bref, désolé de ce long message, mais tout ça pour dire que ça faisait au final un peu de temps qu’on pensait à quitter SVN à cause de sa gestion des branches, et DJ Fox nous a décidé. Donc oui en quelque sorte c’est « à cause » de vous. ^^

  3. Euh, je suis d’accord que la gestion des branches n’est pas ce qu’il y a de plus fabuleux sous SVN, mais il ne faut pas non plus dire qu’il ne les gère pas. Il ne faut passer à GIT parce que c’est la mode, mais par nécessité ou parce qu’on en tire un réel bénéfice. Je suis sûr que plus de 60%(voir 80%) des personnes qui vont suivre le mouvement aurait pu continuer à tout faire sous SVN mais ne se sont juste pas renseignée ou n’ont pas bien configurées leur serveur.

    Sinon, je suis également intéressé par un exemple de « surveillance du contenu ».

  4. Cogito oui, c’est bien le nom, mais je crois bien qu’il est abandonné.

    Autocrlf on connaît, et ça nous a donné plus de maux de tête que quand c’était désactivé, donc on a arrêté de l’utiliser. Tout le fichier était modifié automatiquement, et du coup bonjour les merge :/

    Je me suis peut-être mal exprimé pour le fait que Git surveille le contenu et pas les fichiers. Disons que c’est dans la nature de son fonctionnement : il a connaissance du contenu, pas des fichiers, d’où la phrase « Git tracks contents, not files ». On en parle notamment ici : http://git.or.cz/gitwiki/GitFaq#Doesgittrackallfiledataandmetadata.3F

    Dans la pratique, c’est ce qui lui donne certainement sa rapidité de fonctionnement et sa flexibilité, mais on touche là au fonctionnement interne de Git. C’est intéressant de le savoir, mais je n’irai pas chercher plus loin.

    A noter que de ce fait, Git n’enregistre pas les dossiers s’ils sont vides. Et il ne retient pas les permissions sur les dossiers. Il faut donc le savoir, c’est dans sa nature de fonctionnement. Je n’ai pas d’exemple sous la main, il faut juste essayer Git pour comprendre le concept.

    Sinon, je n’ai jamais dit que SVN ne gérait pas les branches, mais que c’était la gestion des branches de Git qui nous avait décidé. D’ailleurs, j’avais bien dit qu’avec SVN ça existait mais qu’il fallait entre autres copier tout le projet.

  5. Ok, je vois un peu mieux ce que tu veux dire. En fait, ce n’est pas une spécificité de Git mais d’à peu près tous les VCS modernes (Git, Mercurial, Bazaar et Darcs en tout cas).

    Pour la rapidité de fonctionnement de Git, les tests montrent qu’entre Git (codé en C) et Mercurial (codé en Python) c’est en fait très proche. Mais ça vient du fait que Git supporte énormément de fonctionnalités de base alors que Mercurial préfère faire via des plugins.

    Pour autocrlf je n’avais jamais entendu parler de ces problèmes, je vais me renseigner un peu plus là dessus.

    Ah, et ne vous plaignez pas trop de msysgit, c’est une superbe évolution par rapport à il y a un an : c’était bien pire avec le port basé sur cygwin, les opérations sur les fichiers étaient totalement émulées par la sous-couche cygwin et elles prenaient donc chacune environ 10x plus de temps que maintenant, rendant le truc totalement inutilisable.

  6. msysgit ce n’est rien d’autre qu’un package contenant cygwin + git + openssh en fait. Donc je ne crois pas que ça soit plus rapide, vu que c’est cygwin derrière. Il faudrait vraiment faire une version de git pour windows ! Là, les merge sont super lents par rapport à windows. C’est toujours « utilisable » tant que y’a pas trop de merge, mais si on pull pas pendant 2 semaines, ça finit bien par prendre 1 min à merger !

  7. C’est quand même dommage d’avoir choisi Git si vous aviez besoin d’un truc multi-plateforme, car ce n’est clairement pas dans ses objectifs il me semble.

    Mercurial est comparable et sans doute plus pratique si vous avez des développeurs sous de multiples systèmes.

  8. Billet très intéressant.

    Je souhaite juste revenir sur le point des zCorrecteurs. En fait, ce n’est pas tant que l’on cherche à faire toujours comme le sdz que les limites de Subversion qui nous poussent à chercher un autre gestionnaire de versions. Il y a maintenant quelques mois, vincent1870 a posté dans le forum de développement un sujet pour que l’on en discute et on a comparé plusieurs gestionnaires de version, notamment Bazaar, Git et Mercurial (comme mentionné par vincent1870 quelques commentaires ci-dessus). On a été tenté par Bazaar un moment mais il s’avère que celui-ci est apparemment très lent, un des défauts que je reproche déjà à Subversion. Restaient Mercurial et Git, je ne me souviens plus exactement de tous les détails qui nous ont permis de les départager, mais il y avait entre autres le fait que DJ Fox utilisait déjà Git et en était très satisfait, et le fait qu’il corrigeait beaucoup des problèmes de Subversion (notamment les branches), sa rapidité etc. Enfin je n’irai pas jusqu’à nier toute influence de la part du sdz dans ce choix (ça a sans doute un peu joué), mais ça n’a pas été le critère principal, loin de là, et on a longtemps hésité à prendre bazaar…

    Ceci dit, le fait que Git soit mal compatible avec Windows reste un réel problème car si la majorité de nos développeurs sont sous Linux ça n’est pas le cas de tous et c’est surtout ça qui nous fait encore hésiter d’ailleurs…

  9. @Ziame: Bah envisagez Mercurial pour les zCos si c’est plus adapté : sa gestion des branches est (bien qu’un peu moins complète que celle de Git) superbe par rapport à celle de SVN, il est totalement multiplateforme avec des tools tels que TortoiseHG et est très rapide. De plus il est assez simple à prendre en main que ce soit pour un habitué de Git ou de SVN (on trouve des introductions avec les équivalences des commandes dans les deux cas). Pour les CRLF je l’utilise depuis maintenant 3 semaines sur du mixte Windows/Linux et je n’ai pas eu un seul problème, tout est automatique.

    Et au moins ça sera une bonne raison de dire que vous n’essayez pas toujours de faire comme le SdZ :) .

  10. J’ai utilisé mercurial dans un système GNU/linux et Windows. À l’aide de TortoiseHg, disponible sur les deux systèmes. Je n’ai rencontré aucune difficultés. Mercurial est vraiment très prometteur.

  11. Je me permets d’indiquer ici même si ce n’est pas le sujet principal de la conversation, mais en réponse à Delroth principalement que nous venons de nous décider pour Mercurial. :) Ce qui nous a convaincu est son usage plus facile et sa prise en main plus rapide que Git, sa rapidité par rapport à Bazaar ou SVN, sa stabilité ainsi que sa compatibilité avec Windows (vu que la moitié de nos développeurs utilisent cet OS).

    Au niveau des fonctions, ça m’a l’air honnête avec un vrai support des branches et des tags, et toutes les fonctions que supportait SVN. Après quelques tests ça m’a l’air très maniable, et j’ai été séduit par les messages explicites (notamment en cas d’erreur, où la commande adéquate pour réparer est indiquée explicitement). Bref, je suis conquis. :)

  12. Comme j’ai dit il y a deux news:
    « c’est une bonne suite, un bon décrochage en même temps
    en tant que débutant je me pose seulement une question:
    où peut-on apprendre le postgresql
    où peut-on apprendre à gérér son site comme vous le faites?
    o_O :-° »
    Bonne progression!

  13. Pour me faire une opinion sur Mercurial, puisqu’il serait stupide de comparer en ayant tester que l’un des deux, je l’ai testé sur deux projets.

    Il faut dire qu’après avoir utilisé git, c’est tout simplement un grand bol d’air frais.

    Comme avec Subversion, on a beaucoup moins la pression de la mauvaise utilisation. On ne se pose pas 36 000 questions pour faire une action.

    C’est simple, cohérent, rapide, multi-plateforme.
    Les dépôts sont propre et ne nécessite pas de maintenance (pas de git gc régulier)

    La syntaxe est beaucoup plus proche de celle de Subversion et on a tous les avantages du décentralisé.

    C’est donc une preuve que l’instinct Gregger n’est pas forcément la marche à suivre.

    Git est connu car Linus l’a présenté en vidéo chez Google !

    AMHA, il est plus facile de passer à Mercurial depuis Subversion que depuis Git. On a en effet des réflexes différents.

    La gestion des branches avec Mercurial est beaucoup plus évidente qu’avec git (où l’on ne peut pas travailler simultanément sur deux branches en même temps).

    Bien sur c’est un investissement supplémentaire d’étudier un nouveau SCM et de l’utiliser à son tour. Il y a une période de documentation …

    Mais avec Mercurial, c’est simple, rapide, multiplateforme et très efficace. Je vous le recommande.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Plus d'articles sur ce sujet