J’ai commencé il y a quelques mois à modifier pour mon usage personnel un logiciel open-source. Son code étant hébergé dans une base Subversion (svn) sur SourceForge, j’avais tout simplement fait un « svn checkout » du projet et commencé à taper dans le code pour faire mes modifications.
Et puis un jour j’ai voulu soumettre un patch aux développeurs. Problème : si je fais un « svn diff », j’obtiens tous mes changements en vrac. Comment faire ? Éditer le diff à la main n’est pas très pratique et source d’erreurs. Faire un deuxième checkout et y copier-coller à la main ce que je veux intégrer au patch est fastidieux.
J’ai donc décidé d’utiliser Git et sa supériorité écrasante (si si, il parait) dans la gestion des branches pour créer mes futurs patchs. L’idée est de créer une nouvelle branche pour chaque patch. Ensuite un simple diff entre deux branches permet de générer le patch souhaité.
La méthode pas à pas
Voici comment ça marche :
1) Récupérer le projet
git svn clone https://…
Ça peut prendre très longtemps car ça récupère tout l’historique du projet. Dans mon cas, ça a pris dans les 2 heures pour environ 5500 révisions svn.
Cette opération crée automatiquement une branche nommée « master » dans laquelle on ne fera jamais de commit. Ça sera la branche de référence permettant de générer les patchs.
2) Créer une branche dédiée à notre premier patch
git checkout -b my-great-patch master
3) Coder le patch… et faire autant de commits que l’on souhaite
- pour voir les fichiers modifiés :
git status
- pour vérifier ce qu’on a changé avant de commiter :
git diff
- pour commiter :
git commit -a -m "Description du commit."
4) Générer le patch
git diff master >my-great-patch.diff
5) L’envoyer aux développeurs
6) Supprimer la branche
Si le patch est intégré au code source officiel du projet, vous pouvez alors supprimer la branche :
git checkout master
git branch -d my-great-patch
La méthode est au final assez simple et je peux confirmer que les développeurs n’ont aucun souci avec les patchs créés par git ;-).
Autres commandes
Il y a tout de même quelques autres commandes à connaitre :
- Récupérer la dernière version du code source officiel
D’abord mettre à jour la branche master :
git checkout master
git svn rebase
Puis mettre à jour la branche sur laquelle vous travaillez :
git checkout my-great-patch
git rebase master
Il peut arriver qu’il y ait des conflits à cette étape, mais je n’ai pas d’instructions détaillées à proposer dans ce cas de figure. Git indique lui-même les commandes à taper pour annuler ou continuer la mise à jour.
- Voir les branches existantes et savoir sur laquelle on se trouve
git branch
- Passer d’une branche à une autre
git checkout my-other-great-patch
Notez que si vous avez compilé la branche my-great-patch avant de passer à la branche my-other-great-patch, il faudra probablement faire un « make clean » pour effacer tous les fichiers générés du projet avant de le recompiler (utilisez
ccache pour gagner du temps !).
Notez également qu’une pression sur TAB complete tout seul les noms de branche git (sous zsh / Arch Linux). Très pratique :-). Il est également possible de configurer son prompt pour qu’il affiche le nom de la branche courante (je vous laisse chercher comment ; je ne l’ai pas fait).
- Voir le log des révisions svn
git svn log
(C’est totalement indépendant de la branche git courante.)
- Voir le log des commits de la branche courante
git log
Combiner tous les patchs
Si en attendant que vos patchs soient acceptés vous voulez les utiliser en local, il peut être intéressant de créer une branche combinant toutes les autres… À priori le plus simple est d’utiliser « git merge » :
git checkout -b all-my-patches master
git merge my-great-patch
git merge my-other-great-patch
Voilà pour cette fois. Have fun ;-).
