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.
