Dans le dernier article, j’ai présenté des idées sur… un peu tout, cette fois-ci je vais être plus spécifique : le rapport entre Git et Subversion.

J’ai vu beaucoup de personnes passer de Subversion à Git, et la plupart tentent de convertir les commandes svn en commandes git. Pas de bol : cette approche ne fonctionne pas.

Git n’est pas Subversion, alors arrêtez de l’utiliser de la même manière !

N’y voyez pas une critique sauvage de cet outil, juste un conseil pour éviter de vous prendre les pieds dans le tapis.

Git manipule certains concepts qui sont (pour l’instant ?) étrangers à Subversion. Cela lui confère plus de puissance (en tout cas là dessus) mais le rend aussi plus complexe. Vous ne pouvez pas masquer cette complexité dernière des scripts ou des alias : vous engrangerez les problèmes incompréhensibles…

En fait, le plus simple c’est de désapprendre Subversion. Oubliez ce que vous savez, et apprenez la gestion de sources vue par Git.

Voici 3 exemples pour illustrer mes propos :

L’index

L’index est un espace dans lequel Git stocke les modifications qui seront incluses dans le prochain commit.

Le but est de permettre de manipuler finement les modifications enregistrer. Il est possible de modifier à la volée une modifications à enregistrer (très utile pour ne commiter qu’une partie des modifications, ou bien pour séparer un ensemble de changements en plusieurs commits) voire — pour ceux que ça amuse — d’enregistrer l’index pour le réutiliser par la suite.

L’utilisateur de Git est donc forcé de peupler son index avant de commiter.

Note : J’ai cru comprendre que les développeurs de Subversion songent à lui en fournir un aussi. Mais bon, on s’en fout un peu en fait, ce qui compte c’est la manière dont vous l’utiliser maintenant ;-)

Les branches

Bien évidemment, Subversion aussi possède le concept de branches, et ce depuis bien plus longtemps que Git (étant donné qu’il est plus vieux :p), cependant la manière de les appréhender est très différente.

Alors, je ne vais pas rentrer dans les détails ici, mais sachez juste qu’il est parfaitement normal — et très courant — de créer une branche avec Git et de la supprimer plus tard. Le modèle rend les branches très légères et totalement décorrélées des commits. Par exemple vous pouvez supprimer une branche que vous venez de merger : vous conserverez l’historique de tous les commits effectués dans cette branche.

Tiens j’en profite pour glisser un avantage de Subversion, histoire de : il permet de réaliser un même commit sur plusieurs branches d’un coup. Git quant à lui forcera à créer un commit sur une branche, puis à le copier (ou merger) dans les autres. Et toc !

Une utilisation normale de Git n’est pas cantonnée à une branche principale. Il faut donc savoir les manipuler.

La décentralisation

Le fer de lance des pro-Git.

Le concept est assez simple en fait : Git manipule des dépôts. Le dossier dans lequel vous travaillez, contient un dépôt. Toutes les modifications que vous faites (commit, changement de branche, rebase, diff, …) sont effectuées au sein de ce dépôt local, et vous pouvez vous synchroniser avec d’autre dépôts (dits distants).

Ce concept n’est pas du tout présent chez Subversion, donc les comparer là dessus n’aurait aucun sens. Cependant notez que pour partager des modifications, un utilisateur Git ne peut pas se contenter de commiter, il doit aussi synchroniser son dépôt avec celui de ses collègues.

Exemple

Voici une utilisation commune de Subversion :

# 1. Je commit les fichiers qui m'intéresse
svn commit file1 file2

# 2. Si le commit n'a pas marché, je merge puis re-commit
svn merge
svn commit file1 file2

# 3. Le collègue se met à jour
svn update

Soit 1 action pour envoyer sa modification, 1 action supplémentaire en cas de problème, et 1 action pour se mettre à jour.

Voici maintenant la version Git :

# 1. J'ajoute les changements qui m'intéressent à l'index
git add file1 file2
# 2. Je commit
git commit
# 3. Je push sur un dépôt commun
git push origin master
# 4. Si le push n'a pas marché, je me replace et re-push
git rebase origin/master
git push origin master

# 5. Le collègue se met à jour
git fetch
git rebase origin/master

Soit 3 actions pour envoyer sa modification, 1 action supplémentaire en cas de problème, et 2 actions pour se mettre à jour.

J’ai volontairement découpé les commandes, pour montrer tout ce qui doit être pensé pour Git.

Conclusion

Si vous pensez qu’on peut traduire « svn commit » par « git commit -a », alors relisez ce chapitre, voire le git book.

Si vous pensez qu’on peut le traduire par « git commit -a && git push », c’est que vous êtes encore bloqué dans le modèle de Subversion. Continuer la lecture de cette série d’articles, et j’espère qu’à la fin (voire avant) vous aurez changé d’avis.

Sur ce, rendez-vous au prochain épisode, git push.