Comme beaucoup de développer web, j’utilise un gestionnaire de version, outil indispensable lorsque l’on commence à bossé sur des projets de moyenne et grande taille. J’ai fait le choix on ne peut plus classique de Subversion alias SVN.
J’ai longtemps travaillé sans, en direct sur le server de prod, parfaitement « à l’arrache ». Mais on s’aperçoit vite que cela à des limites lorsque que l’on veut modifier profondément un projet.
Je me suis alors monter un server SVN afin de pourvoir créer des branches, revenir sur une modification fait à la va vite, avoir un historique des changement (le but principale d’un server de version).
Un server SVN demande également une certaine rigueur, j’ai chercher un peu sur le net quelles étaient les bonnes pratiques. Et là je doit avoué que j’ai pas trouvé grand chose de concret. Alors bien sur on trouve des choses assez évidentes comme SVN n’est un server de back-up, ne pas commiter du code non fonctionnel (erreur de syntaxe), ne pas versionner des fichiers binaires….
Mais peut parle de convention de commit, au début je faisait des commit du genre :
ajout de la fonction truc muche du module post
suppression du bug qui empêchait de faire quelque chose super important dans le plugin postit
modification de la variable de la fonction machin dans le fichier index.php
Après j’ai fait comme suis
1) Module actualité
- Ajout d’une fonction de trie de tableau
- Ajout de commentaire
2) Plugin postit
- Modification du label
Finalement je procède comme suit
* Core
- [add] function arraySort() issue #559
- [mod] function login()
- [del] param $default in fonction makeMenu()
* Module actualité
- [fix] function getRead() bug #253
- [miss] complete coment for function markRead()
Alors ma façon de faire n’est pas la meilleur mais elle me convient et c’est bien là le principale. Mais voilà lorsque l’on regarde un peu en arrière on se rend compte que le fait d’avoir 36 convention de commit devient vie déplaisant à lire. Mais c’est trop tard le server SVN à tous enregistrer et se souvient de tous tout comme votre gestionnaire de projet.
Alors que faire ? Rassurez vous Subversion à plus d’un tour dans son sac.
Sur votre server créer un fichier contenant votre texte de commit pour l’exemple nous l’appellerons « nouveau_commit.txt ».
Puis lancer la commande :
svnadmin setlog –bypass-hooks /__chemin__/__du_depot__/__nom__du__depot -r __numero_de__la__revision nouveau_commit.txt
Si vous utilisé Redmine, ce dernier réimportera vos nouveaux commit, ainsi vous aurez un historique de vos révisions avec le même formatage.