29 avril 2010

Let's GIT !

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.

4 commentaires:

Bouiaw a dit…

Avant de tester les 2 (Git/Mercurial) j'étais pro Git : pleins de projets Open Source l'utilise, il est super puissant, etc.

Cette impression positive était d'ailleurs à mon avis plus du à GitHub qu'à Git lui même.

Finalement, après avoir tester en détail les 2, pour un usage en entreprise nous avons choisi Mercurial sans hésitation pour les raisons suivantes :
- Support de Windows parfait
- Intégration dans Eclipse géniale avec hgEclipse
- Passage de Subversion à Mercurial bien plus facile
- Plus simple d'utilisation, documentation exellente
- Meilleur support HTTP derrière un proxy d'entreprise

Une seule solution pour faire le bon choix : essayer les 2 et ne pas se baser uniquement sur des impressions.

IceWil a dit…

Moi j'ai choisi GIT pour la vitesse, je travaille dans un environnement assez lent donc j'ai choisi le plus rapide d'après les benchmarks (GIT est loin devant)

Spawnrider a dit…

"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..."

Si je comprends bien, tu utilises Git pour versionner tes modifications en local et ensuite tu synchronise le tout sous SVN en un commit atomic? J'avoue que l'idée d'utiliser le versionning en local pour annuler une modification effectuée me paraît être une bonne idée pour des projets complexes avec beaucoup de petites modifs dans plusieurs fichiers.

Par contre, une fois tout ton bouzin livré, tu perds les révisions Git effectuées en local? ça se passe commment?

nicolas deloof a dit…

Git via git-svn peut se synchroniser avec SVN et donc envoyer tes modifs après réorganisation, donc en effet tu "revois" l'historique de ton commit. En gros, tu bosse comme un porc en tripatouillant partout, en faisant plein d'essais et tout ça, et dans le log SVN il n'y a qu'un commit unique avec tous les TestU au vert super propres ;)