Utiliser Git même si votre équipe ne le fait pas : trucs et astuces git-svn

Nicola Paolucci
Nicola Paolucci
Retour à la liste

Avant de rejoindre Atlassian, je travaillais sur divers projets qui faisaient encore appel au système de contrôle de version Subversion (SVN). J'étais déjà passé à Git des années auparavant et je voulais continuer de l'utiliser autant que possible.

J'ai eu la chance de pouvoir utiliser git-svn : Une solution extrêmement complète qui interagit avec les dépôts Subversion depuis le puissant ensemble d'outils Git. Cependant, il y a quelques pièges. Ce billet suppose que vous êtes déjà familiarisé avec git-svn et que vous savez comment interagir avec un dépôt SVN basé sur cette commande.

La liste ci-dessous contient tous les trucs et astuces que j'ai dû rechercher et intégrer à mon workflow pour continuer à utiliser Git avec SVN. Bonne lecture !

Configurer les fichiers à ignorer

Vous devez vous assurer que Git ignore les mêmes fichiers que SVN. La méthode la plus simple consiste à ajouter la liste des fichiers svn:ignore au fichier d'exclusion par défaut de Git :

git svn show-ignore >> .git/info/exclude

Par ailleurs, la commande update-index offre une solution magique :

git update-index --assume-unchanged files to ignore

This is quite a fine trick, and I've consistently used in the past year. If you need more information, have a look at this post on Stackoverflow. If you use the latter method, how do you find out later that a file has been ignored in Git? You can use this:

git ls-files -v | grep ^[a-z] | sed -e 's/^h\ //'

REMARQUE : update-index est une commande avancée qui manipule l'index directement. Il faut donc l'utiliser à bon escient !

Clonage superficiel des dépôts volumineux

Je l'ai utilisée avec des bases de code SVN de plus de 1,5 Go pour un checkout complet. Dans des scénarios similaires, le checkout de tout l'historique commit par commit (à la manière de git-svn) peut s'avérer lent, car le dépôt est trop volumineux. Pour contourner ce problème, vous pouvez créer un clone superficiel du dépôt. Au lieu de copier tout l'historique du projet, vous copiez simplement les n derniers commits avant de continuer. Par exemple :

git svn clone -s -r604:HEAD http://nick@svn.xxxxxx.com/repos/ -T trunk -b branches -t tags

Sachant que « 604 » doit être remplacé par la révision antérieure que vous souhaitez conserver. Référence Stack Overflow obligatoire.

Si vous avez ajouté les dossiers .svn à Git par mégarde

Tôt ou tard, vous aurez des ennuis. Par exemple, il m'est arrivé de ne pas utiliser git svn ; j'ai simplement extrait un projet de SVN, mais je voulais effectuer mon propre suivi avec Git. Cette fois-là, j'ai ajouté par mégarde les dossiers .svn à l'index (zone de staging) dans Git. Comment conserver ces fichiers indispensables tout en les supprimant de l'index ? C'est plutôt complexe ! Voici comment annuler le suivi de fichiers sans les supprimer de Git :

git status -s | grep .svn | awk {'print $3'} | xargs git rm --cached

En l'occurrence, le mot-clé est --cached, qui fonctionne sur l'index, et non dans le répertoire de travail. Pour obtenir une explication claire, consultez ce chapitre sur Pro Git.

Que faire si un dépôt SVN est déplacé

Lorsqu'un dépôt SVN est déplacé (ou que vous devez y accéder via un VPN et appliquer une stratégie de tunneling qui changera son adresse), vous devez suivre la procédure correcte pour éviter une ré-extraction complète. La première méthode figurant dans le wiki Git est celle avec laquelle j'ai eu le plus de succès. Voici la partie la plus importante du wiki :

  • Modifiez l'URL de svn-remote dans .git/config pour indiquer le nouveau nom de domaine ou la nouvelle adresse IP.
  • Exécutez git svn fetch. Au moins une nouvelle révision issue de svn devra être fetchée !
  • Remplacez l'URL de svn-remote par l'URL d'origine.
  • Exécutez git svn rebase -l pour effectuer un rebase local (avec les changements apportés lors du dernier fetch).
  • Remplacez l'URL de svn-remote par la nouvelle URL.
  • Exécutez git-svn rebase. Maintenant, tout est rentré dans l'ordre !

Ceci fonctionnera uniquement si un élément est fetché lors de l'étape git-svn fetch !

Conclusion

Travailler avec Git est un réel plaisir pour moi. Je dispose d'un contrôle complet et d'une liberté totale, je peux faire des commits à l'infini, les reformater, les compresser pour obtenir des commits nettoyés et créer des branches à ne plus savoir qu'en faire. Même lorsqu'il est combiné avec SVN, l'outil procure le même plaisir. C'est ce que je fais depuis deux ans et ça fonctionne à merveille.

Lorsque toute votre équipe est prête pour la migration vers Git, un guide étape par étape complet peut s'avérer très utile. C'est pourquoi nous en avons élaboré un :

Le guide facilitant la migration de SVN vers Git !

Prêt à découvrir Git ?

Essayez ce tutoriel interactif.

Démarrez maintenant