On me demande souvent sur ce blog (ou dans ma tête, je ne sais plus, bref) pourquoi j’ai choisi Git au lieu de Mercurial ou Subversion (pour les plus connus) comme VCS.

La petite histoire :

Quand j’ai commencé à utiliser un VCS il y a de ça quelques années, c’était Subversion. J’avais rapidement connu CVS, mais je le détestais déjà à cause des multiples commandes obscures a rentrer rien que pour faire un checkout.

Pendant mon stage à Air France Industrie où j’ai développé une application embarquée pour un boîtier de tests d’équipements avioniques (ça fait toujours bien de le dire), j’ai du coder sur mon propre portable (trop de stagiaires, pas assez de pcs) et déconnecté de tout réseau pour des raisons de sécurité (ie. admins nazis).  J’allais donc m’attaquer à l’installation de Subversion sur ma propre machine pour pouvoir commiter en local, et je me suis dis que c’était quand même un peu brutal. J’ai donc commencer à chercher des alternatives, comme ça, à tout hasard.

Et là, je découvre les VCS décentralisés. Et parmi la liste de ceux existants, mon attention est retenue par Git, qui a été codé par Linus Torvald, rien que ça. Je me dis que ça m’a l’air d’être un bon gage de qualité, et puis on trouve plein de gens sur le net qui en vantent les mérites (de Git, pas de Torvald. Quoique…).

La fête commence

Et donc je découvre les joie de Git :

• git init pour créé un depot, pas besoin d’installer un demon et de faire tout un bordel et des sacrifices de vierges.
• git stash,  qui permet de mettre son boulot en cours de coté pour retrouver un depot clean comme au dernier commit. Je pourrais en dire du bien pendant des heures.
• git branch, avec qui on peut faire des branches locales à tout va, et son copain git merge qui permet de les réunir. On ne peut plus s’en passer une fois qu’on a essayer.
• git rebase -i, qui permet de changer l’ordre des commits, d’en supprimer, ou encore d’en fusionner. Attention commande dangereuse quand même, elle réécrit l’histoire.
• git reflog qui permet de retrouver sont dépots tel qu’il  etait (insère ici une indication temporelle), c’est pratique quand rebase t’a perdu un commit, chose qui arrive malheureusement.
• stgit, c’est un autre programme qui permet de faire comme rebase, mais en plus souple. on peut créer, modifier, et changer l’ordre des commits à la volée, avant de les commiter définitivement pour les partager.
• commit -i, qui permet de ne commiter que les hunk que vous voulez, voir même ligne par ligne (moi je passe par git gui, c’est bien pratique). Un bon exemple : J’ai modifier à plusieurs endroit un fichier de config pour l’adapter a ma conf, et je veux commiter une modification sur une seule valeur. Un autre VCS m’obligerai a commiter le fichier entier avec toute mes valeurs persos, alors qu’ici je vais pouvoir ne commiter que la ligne qui est intéressante pour tout le monde.
• pleins d’autres trucs cools…

Et Mercurial alors ?

J’entends déjà : « Oui mais Mercurial il peut faire tout ça aussi gna gna gna» . Presque, et seulement quand ça marche… J’ai eu l’occasion de le tester réellement un jour où on à du faire un projet obligatoire pour l’école. J’étais le chef de projet, et l’autre codeur (on était 4 en fait, dont 2 qui ne servaient à rien) ne connaissait que Subversion. Je me suis dis que git allait lui faire peur, donc on a tenté Mercurial.

Je ne vais pas citer toutes les fonctions qui marchent pareil, je vais vous parlez de ce que j’ai détesté avec Mercurial :

• L’extension qui fait pareil que git stash n’est qu’une extension, j’ai eu un mal de chien à la trouver (il y a une page de wiki qui parle de l’extension, de comment l’installer, mais pas de lien pour la télécharger. il faudra les archives de la mailing list, ou tu pourra trouver l’extension en brut comme ça, directement dans le mail. Bien sûr au premier essai gros crash de python, elle était sûrement pas à jour. Je viens de vérifier, il y a maintenant sur la page wiki un adresse du dépot ou le télécharger, donc je lui laisse le bénéfice du doute.
• Les branches locales (dans le même dossier) n’existent pas, il faut faut faire des clones de dossier. Quand on utilise un IDE qui se base sur un dossier, ça devient tout simplement pas utilisable. On me signale dans mon oreillette qu’une extension expérimentale est sortie… Ça promet…
• Pas de rebase -i, ne de reflog.
• Une extension, mq, qui permet de gérer une file de patch/commit, de la même manière que stgit. Alors déjà même si elle incluse de base, il faut l’activer par le fichier de configuration, et ce genre de pratiques qui consistent à cacher des commandes en prenant l’utilisateur pour un neuneu m’énerve. Mais soit, c’est pas ça qui va m’arrêter. Le problème, c’est qu’au bout de quelques commits, paf, crash. Suite à ça, dépot inutilisable, il n’acceptait plus aucune commande. J’ai du aller récupérer à la main les diffs de mes commits dans le dossier .hg, et recréé un nouveau dépot. J’ai testé plusieurs fois, je me suis pris plusieurs crash dans le genre… Pourquoi ?! J’ai tout fait conformément à la doc, et j’utilisais une release de Mercurial, pas la version de développement, alors pourquoi ça me plante tout régulièrement ??
• Enfin, quand on commit, on doit commiter toutes les modifications d’un coup, à la manière de subversion. Il existe à priori une extension qui permet de fait du commit sélectif à la manière de git, mais vu tout les problèmes que j’ai eu avec les extensions, je vous laisse la tester.
• Sûrement pleins d’autres trucs haïssable que je n’ai plus en mémoire.

Au final :

J’ai souvent entendu dire : « Git c’est codé à la sale en C et en bash, ça donne pas confiance, alors que Mercurial est bien propre et en python» . Ça me fait bien rire. Je n’ai jamais eu de problème de stabilité avec Git, alors que Mercurial m’a crashé le dépôt un nombre incalculable de fois. J’avais vraiment l’impression d’utiliser un truc en beta.

Qu’on le trouve bien tant qu’on reste dans les commandes standards, c’est à dire en ne s’en servant que de la même manière que subversion, ok, pourquoi pas.

Mais quel est l’intérêt ?

Nouvelle vie, nouveau blog. J’entends déjà une petite voix qui me dit : « Pourquoi nouveau blog, c’est ton premier ?!» .

Petite voix, tu pose trop de questions.