17 août 2010

From SVN to Git

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.


Le travail avec l'équipe
Dans ce mode, SVN reste le dépôt de référence du projet, donc il va bien falloir faire le lien avec le reste du monde.





Créer le repo Git/SVN : 
git svn clone -s [urlsvn] -r yapalongtemps:HEAD

le -r permet de limiter l'historique pour ne pas avoir un repo Git trop gros en indiquant un numéro de révision SVN de départ.
-s pour "standard", trunk/branches/tags. Si votre URL svn ne commence pas à ce niveau, ajoutez -T avec le dernier niveau de répertoire comme si c'était le "trunk".

Si vous utiliser une saloperie de proxy non transparent, vous devrez peut être éditer $HOME/.subversion/servers pour ajouter vos identifiants, et/ou définir la variable d'environnement HTTP_PROXY

Exclure les fichiers non versionnés : 
il faut créer des .gitignore pour les fichiers exclus (.classpath, .project, target ...). Il est dommage qu'il n'y ai pas une synchronisation entre ce fichier et les svn:ignore, mais bon c'est pas la mort. En plus, ça va attirer l'attention de quelques curieux qui viendront vous voir pour découvrir Git à leur tour :P

Committer ses modifs : 
git svn dcommit
Git va rejouer tous vos commits sur SVN. C'est là que la réorganisation de vos commits et des logs associés peut être intéressant pour vous la jouer "j'ai tout fait super propre en un seul coup". Cela va surtout éviter de committer des bouts de trucs inconsistants qui pénalisent tout le monde, comme on le fait trop souvent sous SVN.

Mettre à jour son environnement :
git svn rebase
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
git checkout maTache 
git stash pop

"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 

Savoir où on en est après une soirée un peu trop arrosée (une soirée au ParisJug par exemple) :




git status
indique les modifications en cours, fichiers non suivis, etc
git branch  

indique les branches existantes, quand on a oublié le nom qu'on leur a donné



Faire un gros ménage après un cafouillage
git reset --hard HEAD
toute les modifs non committées partent à la poubelle. C'est l'équivalent du svn revert.
en indiquant un ID de commit on peut même revenir en arrière pour changer le futur (à la McFly).





J'espère ne pas avoir dit trop d'âneries et que ça vous aidera pour vos premiers pas avec Git.










7 commentaires:

Chouan a dit…

Excellent article. Je me mets également à Git après avoir utilisé SVN et ce petit récapitulatif est d'une grande aide.

Si possible, n'étant pas encore un "Git power user", j'aimerais avoir plus de détails (un bon lien par exemple) sur la partie "C'est là que la réorganisation de vos commits et des logs associés peut être intéressant".

Damien Cassou a dit…

Je suppose que la première commande c'est 'git svn clone ...' et pas 'git clone ...'.

nicolas deloof a dit…

@Chouan http://progit.org/book/fr/ch6-4.html
@Damien bien vu, je corrige

Chouan a dit…

Merci pour le lien. Bon... il va me falloir un peu de pratique pour assimiler tout ça et pour que ces commandes deviennent naturelles.

ssaboum a dit…

C'est bien vu et merci pour cet article sur l'intégration Git/Svn. Dans le cadre de mon boulot et pour plus de flexibilité j'ai mis en place un mecanisme de double versionning Mercurial/CVS avec une passerelle (mono-branch) et un clone (avec une branche par fiche/expérimentations).
Ca se fait bien aussi si ca t'intéresse n'hésite pas à me contacter.

http://twitter.com/ogirardot

Arnaud a dit…

Pour les ignore je viens de trouver cela sur le net :
git svn show-ignore >> .git/info/exclude

nicolas deloof a dit…

oui, j'ai vu passer cette commande aussi (variante : git svn show-ignore > .gitignore)

par contre c'est TRES TRES long, donc à lancer le soir avant de partir.

Il ne manque plus qu'à trouver l'opération inverse et c'est la fête