new Blog( perso );

Depuis que j'ai découvert Git j'ai du mal à m'en passer. Lorsque je suis contraint d'utiliser Subversion je passe par git-svn, ce n'est certes pas idéal mais c'est déjà d'un grand confort.

Pour aider l'équipe Devoxx à adapter leur application sur CloudBees, j'ai du utiliser Mercurial (Hg pour les intimes). Mercurial est très comparable à Git, mais un peu déroutantes pour un Git-iste car les commandes reprennent les même nom mais pour un usage différent (fetch devient pull, pull devient fetch pull, reset devient revert, revert devient backout, etc. Si vous devez faire l'exercice, garder ce tableau sous le coude.

Bref, j'ai eu la flemme d'apprendre Mercurial, ni d'utiliser SourceTree tout en mode graphique parce que... et bien la ligne de commande y'a que ça de vrai, n'est ce pas ?

Il faut savoir qu'il n'existe pas de passerelle officielle hg->git, contrairement à celle qui permet d'utiliser svn. Il existe par contre une passerelle inverse, très mature, qui permet aux utilisateurs de mercurial d'utiliser un repository git: hg-git. La raison de cette absence est apparemment philosophique, si j'ai bien tout suivi ...

Il existe donc pléthore de solution custom pour prendre en charge ce besoin. J'en ai donc testé quelques un pour finalement tomber sur git-remote-hg.

Comme expliqué sur le blog, comparée aux autres solution cette passerelle à l'avantage de se plugger dans les mécanisme de transport de git, et non de chercher à fournir des commands complémentaires du genre "git hg-clone". On travaille donc en pur git, mais avec un repository distant qui utilise le protocole "hg::*".

J'ai donc cloné le repo devoxx, tripatouillé deux trois fichiers de configuration, et voulu pousser tout ça dans bitbucket pour proposer une pull-request. J'ai alors eu un grand moment de solitude :


git-remote-hg fait apparaître les branches mercurial sous l'arborescence "branches", et la branche de développement du projet, équivalente du master git, est donc branches/default. J'ai passé un certain temps à tenter d'attacher mon master à la branche remote origin/branches/default sans succès. Tous les "--set-upstream"n'y ont rien changé. J'ai bien cru que j'allais devoir changer d'outil.

Au final, j'ai crée une branche locale branches/default (les branches git peuvent contenir le caractère '/', le saviez-vous ?) associée à la branche remote origine/branches/default, mergé mon master dedans, et j'ai (enfin) pu pousser tout ça sur bitbucket. Ouf!


Bizarrement, chaque push m'indique la création d'une nouvelle branche remote. Cela fonctionne donc mais l'intégration n'est pas encore parfaite.

Bref, si vous devez vous aussi jongler entre mercurial et git, cette solution semble intéressante, à condition de respecter du 1:1 avec les branches mercurial. Elle permet de synchroniser les repositories sans perte d'information, par exemple pour proposer un miroir Git d'un repo Hg, et vois évite de devoir choisir entre Git et Hg si vous en êtes à ce stade.

Au passage, au cours de mes tentatives j'ai découvert que Perforce venait tenter sa chance sur le territoire Git : http://www.perforce.com/blog/121001/improving-git-experience-everyone. De mon point de vue, question SCM, les jeux sont faits (en attendant le prochain :P)

Lors de ma conférence au JugSummerCamp Emmanuel Bernard a soulevé une question pleine de bon sens :

C'est clair que Git est pénalisé par l'image de Geek qui lui colle à la peau : construit par Linus Torvald, utilisant la ligne de commande avec des options tortueuses, ...

FlashBack :

Quand j'ai commencé à bosser, on attaquait tous en telnet un serveur de dev, sur lequel code source et résultat de compilation était allègrement mélangés dans des répertoire ou tout le monde tapait son code sous vi/emacs, sans plus de gestion de version en dehors de la sauvegarde hebdomadaire sur bande.

Quelques années plus tard, première révolution avec Visual Age et son gestionnaire de version centralisé, basé sur la prise de verrous sur les fichiers. On entre dans un mode de concurrence et de gestion collaborative, où chacun dispose d'une copie de travail dédiée sur son poste de développement.

Plus tard, seconde révolution avec CVS puis SVN : l'absence de verrous permet de travailler sans "subir" les actions en cours des autres développeurs. La problématique des merge apparaît, mais l'outil est tout de même assez efficace pour les gérer, en particulier sous Eclipse qui devient notre environnement quotidien.

Aujourd'hui, les DVCS portent une nouvelle révolution : la séparation du workflow projet et de celui du développeur. Le travail local, basé sur des tentatives multiples, des retours arrière, des recherches dans l'historique, bénéficie pleinement d'un gestionnaire de version. Pour autant, le reste de l'équipe ne subit pas vos diverses branches et commits en tout genre. Le merge de branche devient étonnement efficace, le mot "branche" n'est plus synonyme de "galère".

Il ne fait aucun doute pour moi que les DVCS vont s'imposer, alors to Git or not to Git ?

D'une part, Git est nativement supporté dans Eclipse (bien que ce soit encore améliorable) ce qui devrait faciliter les choses. Les outils graphiques comme TortoiseGit facilitent aussi son utilisation. La ligne de commande reste le plus efficace, mais avec le temps et le murissement de ces outils, on devrait pouvoir s'en passer progressivement (enfin, pour ceux qui veulent).

Reste que les concepts sont encore neufs et qu'il va falloir ses les approprier. Pour ça il faut des précurseurs, qui porteront ainsi le reste de l'équipe et assureront le support de niveau 1 - et Git-svn va nous y aider.

Git-svn permet d'utiliser Git en local avec tous les avantages que cela implique, sans que la référence svn soit impactée. Ceux qui doivent effectuer des opérations non triviales (refacotring), ou bien passer souvent d'une tâche  à l'autre (corrections de bugs), ou encore qui ont une culture geek pourront le tester, l'apprivoiser, puis l'adopter. Contrairement aux autres "révolutions" que j'ai évoqué, celle-ci va se faire en douceur. Une fois que  l'équipe aura utilisé au moins une fois Git sur son poste, le remplacement de SVN sera naturel.

Après tout, il y a 13 ans (putain, 13 ans !) si j'avais parlé de faire une branche alors qu'on avait besoin d'éditer avec vi un même fichier depuis notre telnet, je serais passé pour un geek (en fait, c'était déjà le cas pour d'autres raisons). Je me rappelle aussi une discussion interminable avec un I.Q. lors du passage à CVS, lorsque j'expliquais qu'on travaillait à plusieurs sur le même fichier, sans mécanisme de verrou ...

Aucun DSI n'imposera Git à ses équipes, par contre les équipes qui y ont goûté le réclameront rapidement. Il y aura donc, comme toujours, les boîtes qui savent suivre le mouvement à temps et celles qui courent derrière le train. C'est aussi à toi, fidèle lecteur, de faire du lobbying, selon la catégorie dans laquelle tu veut entrer. Fais toi la main, parles en et montre le à tes collègues, râle un bon coup sur SVN, et le projet "pilote" pointera le bout de son nez.

Vous l'aurez compris, Git est mon nouveau dada. Avec toutes ces années de "centralisé" j'ai tout de même du mal à me sortir de mes habitudes sous Subversion. Voici donc un petit pense bête pour ceux qui sont dans le même cas que moi, et qui ont du mal avec les innombrables options de Git, surtout si on le couple avec le SVN de l'équipe.


Git va faire une update svn puis rejouer toutes les modifs committées en local. Attention de partir d'une environnement propre (cf git slash plus loin)

Ces deux commandes sont assez peu naturelles, l'équivalent sur un repo Git étant git push / pull, mais bon.

Le travail en local

C'est là que Git va montrer son intérêt : Git nous sert à structurer notre façon de bosser là où jusqu'ici on était  obligé, soit d'avoir plusieurs workspaces, soit de "pousser" notre workflow sur le SVN commun, soit d'avoir plein de travaux en cours dans le même workspace et de commiter un peu tout et n'importe quoi (suivi de quelques commits "fix").

On va donc bénéficier d'une gestion de version très puissante et performante en local, plutôt que d'un foutoir plus ou moins organisé.

Démarrer une nouvelle tâche :
git checkout -b maTache


le "-b" crée la branche locale à la volée
faire sa tambouille, je suppose que vous utilisez eGit ou équivalent : add, commit, etc

Faire une pause et passer en urgence sur une autre tâche :
git stash
git checkout monAncienneTache
// correction et tout ça sur monAncienneTache
"stash", c'est la boite à idées de Git, la pile où on met tous les trucs en cours, en attente de "plus tard, quand j'aurais le temps"

Intégrer une branche dans le master une fois que tout marche comme sur des roulettes :
git merge maTache master


supprimer la branche une fois le boulot terminé / validé / livré :
git branch -d maTache 

Je me lance dans un gros refactoring de sauvage, pour lequel un module maven doit être splitté en trois, avec des changements de packages en tout genre et j'en passe.

Pour avoir fait ce genre de manip plus d'une fois, celà se traduit généralement par :

• L'impossibilité de faire l'opération en un seul commit SVN (en tout cas, j'y suis jamais arrivé) : des fichiers déjà modifiés doivent être déplacés ou renommés, et le couple SVN+Eclipse ne gère pas du tout bien la manip
• L'impossibilité totale d'envisager un merge de modifications apparues en cours de route. Le fichier à changé de place et de nom, SVN ne s'y retrouve pas.

Au final, l'opération se fait sur la pause de midi ou - dans mon cas parce que ça ne me dérange pas - tôt le matin, avec deux ou trois échanges de mail pour alerter tout le monde et bloquer les commits.

Cette fois, je tente la manipulation avec Git. 

Tout d'abord, un git svn clone me fournit un repo Git à l'image du SVN projet.

Ensuite, après un premier essai pas très concluant, j'installe un nightly-build du plugin EGit pour contourner ce bug, qui rend EGit quasiment inexploitable (il veut tout le temps committer les target).

C'est parti pour une séance de "bouge ton code". Mettez à fond "I like to move it" et balancez la sauce...

Je ne vous cache pas que j'ai un peu merdé sur mes premières commandes Git. En gros, pendant la première demi-heure on se demande dans quoi on s'est embarqué, et même avec mon ami Google les commandes restent assez obscures. Pendant cette phase d'appropriation de l'outil, ayez le réflexe de garder sous le coude la refcard Git, ainsi que l'excellent open-livre ProGit :P

Après ces premiers faux pas, les réflexes commencent à venir, et je dois bien avouer que la question devient vite "pourquoi n'ai-je pas essayé plus tôt ?"

Pourquoi Git est-il différent ?
La première différence, liée à  l'aspect décentralisé, est de disposer en local d'un repo très rapide pour committer, brancher, revenir en arrière, etc. Pensez au nombreuses fois où vous avez eu recours à l'historique local d'Eclipse pour rattraper une boulette. Et bien là c'est toute la puissance d'un SCM qui est au bout du clavier. Le switch de branche étant quasi instantané, on en profite (on en abuse même) alors que sous SVN c'était l'horreur.

La seconde différence, c'est que la structure de Git se base sur un unique répertoire .git, et pas une invasion de .svn à tous les niveaux. Ca n'a l'air de rien, mais une conséquence immédiate est que les performances I/O du système (dénaturé par une surcouche MacAffee) s'en trouvent bien meilleures. Lorsqu'on déplace un répertoire entier avec SVN, la première erreur consiste à utiliser l'explorateur. Les fichiers .svn n'étant pas mis à jour il n'y à rien à committer. Après s'être fait avoir 2 ou 3 fois, on apprend à faire un "refactor > move" qui se traduit par une série de Remove + Add au niveau SVN, et au prochain merge c'est l'enfer.

Dernière différence significative : en l'absence de .svn pour marquer chaque répertoire/fichier, Git doit retrouver l'identité de chaque fichier modifié lors d'un commit. Il va comparer les fichiers par rapport à son index, et sera capable d'identifier un déplacement, malgré les déclaration "package" ou d'import qui changent. En gros, le fichier le plus "similaire" dans l'index est celui qui a été déplacé. C'est une solution empirique, mais qui marche bougrement bien. D'ailleurs, tout est empirique dans Git, comme les identifiants de commit qui sont des empruntes SHA1 - mathématiquement parlant il y a un microscopique risque de doublon, mais en attendant ça fonctionne très, très bien ! Résultat, le SCM est très souple et les merges ne sont plus un soucis !

Pourquoi Git fait-il peur ?

• Git c'est nouveau, c'est geek, donc forcément ça fait un peu peur.
• Git c'est très "ligne de commande", et quelle ligne ! Même si on s'y fait finalement assez vite, voir quelqu'un travailler avec Git fait penser qu'on est passé du côté obscur.
• Git est mal intégré dans Windows; msysgit est très correct, mais reste une solution ligne de commande, avec quelques outils graphiques bienvenus. TortoiseGit ne m'a pas convaincu, et j'utilise EGit sous Eclipse en complément de la console GitBash.

L'autre raison qui fait que Git va mettre un peu de temps à rentrer dans les moeurs, c'est son aspect décentralisé : le concept est encore assez neuf, et vient en contradiction avec des années d'habitude centralisatrices.

My 2 cents...

Comment bien aborder Git ? Le couplage avec SVN permet de l'expérimenter localement sans impacter le reste de l'équipe (en dehors des fichiers .gitignore qui vont fleurir dans SVN). Ensuite, il faut considérer votre mode de travail local, votre "workflow", indépendamment de celui de l'équipe qui est formaté par SVN.

Sur le poste de développement, on fait plein de choses en parallèle : on revient en arrière, on teste un truc, on change de tâche. On se retrouve donc à committer quelques fichiers par-ci par là, à commiter un item par petites touches. Autrement dit, on pollue le projet de travaux pas finis, et on est sous-outillé en local pour séparer nos diverses activités. Git est un outil qui vient soutenir ces démarches de manière active, il va structurer et assister notre travail quotidien.

Une fois l'habitude de Git en locale prise, les derniers récalcitrants convertis, le passage du point de centralisation sous Git parait une évidence. Avec lui une autre façon d'envisager le projet peut émerger : comment isoler chaque fonctionnalité et les "merger" au dernier moment ? Comment intégrer les correctifs à la demande ? etc...

Que ce soit Git, ou Mercurial (apparemment plus structurant, je n'ai pas testé) ou un autre candidat, les SCM décentralisés vont bouleverser notre façon de travailler.

La grande mode en ce moment en terme de gestionnaire de code c'est Git. La différence avec Subversion, la grande mode de juste avant, c'est que Git est distribué. Super, et alors ?

Prenons une journée type. Vous bossez sur un item qui vous fait modifier du code un peu partout et quelques refactorings bien sympatoches. Arrive alors une urgence bien trempée, un point fonctionnel pas clair qui oblige à temporiser, ou encore une soudaine envie de passer à autre chose parce que là, vraiment, ça n'avance pas.

Que faire ? Lancer un nouveau checkout pour partir sur autre chose et switcher entre deux workspaces Eclipse ? Idéalement, il aurait fallu travailler dans une branche, comme ça passer à autre chose se ferait sans perdre l'état en cours... sauf qu'il aurait fallu le prévoir à l'avance et que la manipulation ne dépende pas de votre réseau de %@! qui semble être basé sur des modems 56k.

Et bien c'est ce que propose Git ! 

Git gère un repository rien qu'à vous dans lequel vous pouvez brancher, switcher, commiter, comparer et tripatouiller tout ce que vous voulez. Etant 100% local, ces opérations sont extrêmement rapides, donc deviennent naturelles (alors que sous SVN elles sont méconnues)

Pour bosser, on commence par créer une branche pour la tâche considérée, et committer dessus à chaque fois qu'on le juge utile. A tout moment on peut changer de branche, tout annuler, revenir en arrière, etc.

Evidemment, à un moment il faut bien envoyer tout ça à ses petits camarades. Mais comme le repo Git est local, on peut remanier les commits effectués pour en faire quelque chose de plus cohérent, ce qui évite l'effet "fix" qu'on constate sur SVN : 1 gros commit suivi de quelques autres pour les fichiers "oubliés". Du coup la synchronisation entre repos Git est nettement plus atomique. Idem pour travailler à deux, on se synchronise entre binômes sans perturber le repository de référence (avec Git, personne ne fait particulièrement référence, mais dans la vraie vie il faut bien se mettre d'accord pour livrer !).

Bref, Git c'est une autre façon de bosser qui va rapidement devenir indispensable, comme à l'époque où on avait pas de SCM et où on partageait tous un montage réseau...

Les points faibles de Git ?

Outil en ligne de commande, il reste particulièrement obscur sur ces options. L'intégration dans les IDE est moyenne avec un retard notable d'Eclipse (quelle surprise). Enfin, le concept étant relativement nouveau il faut apprendre à l'apprivoiser.

Pourquoi se préoccuper de Git ?

Après tout, Subversion marche plutôt bien. Et bien, si le cas d'usage exposé ci-dessus vous laisse froid, sachez que la prochaine version suivante  de SVN (la N+2 quoi) incorporera un mécanisme de distribution, sans doute inspiré par le succès de Git et consorts. Ce n'est donc pas qu'un effet de Geekitude,  mais bien une évolution profonde des SCM, autant être dans les premiers à savoir en tirer partie.

Comment commencer avec Git ?


Pour faire mumuse, Google Code propose un hébergement Mercurial, assez comparable à Git mais qui a moins le vent en poupe ces temps ci (sans de raison évidente).
Le plus concret est d'utiliser Git au dessus de SVN. Le repo local Git peut en effet se synchroniser sur un SVN classique, ce qui permet d'en profiter sur son poste sans perturber l'organisation de l'équipe. Et une fois le pli pris...

Reste à apprendre les commandes assez obscures de Git et l'utilisation du GitBash sous Windows - plateforme qui n'est pas à l'honneur pour cet outil.