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
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 svn rebase
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
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 HEADtoute 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:
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".
Je suppose que la première commande c'est 'git svn clone ...' et pas 'git clone ...'.
@Chouan http://progit.org/book/fr/ch6-4.html
@Damien bien vu, je corrige
Merci pour le lien. Bon... il va me falloir un peu de pratique pour assimiler tout ça et pour que ces commandes deviennent naturelles.
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
Pour les ignore je viens de trouver cela sur le net :
git svn show-ignore >> .git/info/exclude
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
Enregistrer un commentaire