Ce post est plutôt un mémo pour mon usage personnel, mais s'il peut aider quelqu'un j'en serai ravi :).
Voilà donc un mémo traitant des problématiques ou cas d'utilisation que j'ai rencontré.
Pour mémoire, je rappelle que je suis dans un environnement SVN (centralisé) - GIT (en client sur mon poste).
Cas d'utilisation
Switch d'une branche SVN
Jusqu'à présent nous étions sur le ‘master’ côtès Git et en remote nous pointions sur ‘origin/trunk’, sur SVN il y a eu un problème en PROD et donc la nécessité de faire un patch dans une branche.
La branche a été créée côtès SVN mais n'est pas visible avec Git:
et la magie la branche V3.13_MAINT apparait. Maintenant nous somme toujours sur le trunk en local:
1234567891011
$ git svn info
Path: .
URL: https://monserveur:8443/svn/MON_PROJET/trunk
Repository Root: https://monserveur:8443/svn/MON_PROJET
Repository UUID: 2a9a025e-1ade-4945-b3f3-c86421e8e34f
Revision: 2813
Node Kind: directory
Schedule: normal
Last Changed Author: m_lap
Last Changed Rev: 2813
Last Changed Date: 2017-04-18 11:32:21 +0200 (mar., 18 avr. 2017)
Il nous reste plus qu'a créé un branche dont l'origine est cette branche
1234567891011121314151617
$ git branch maint remotes/origin/V3.13_MAINT
$ git branch
maint
* master
$ git checkout maint
Switched to branch 'maint'
$ git svn info
Path: .
URL: https://monserveur:8443/svn/MON_PROJET/branches/V3.13_MAINT
Repository Root: https://monserveur:8443/svn/MON_PROJET
Repository UUID: 2a9a025e-1ade-4945-b3f3-c86421e8e34f
Revision: 2814
Node Kind: directory
Schedule: normal
Last Changed Author: p_che
Last Changed Rev: 2808
Last Changed Date: 2017-04-12 15:20:33 +0200 (mer., 12 avr. 2017)
Et nous pouvons retouver notre flux de travail habituel! \o/
Erreur
Au cours de mes devs j'ai oublié parfois d'ajouter une modification, un paramètre … un dernier petit détails, pour y remédier je fais: git commit --ammend
Puis une fois terminé je pousse sur SVN
git svn dcommit
Et puis un jour dans ma lancé, je refais un git commit --ammmend sur un commit déjà poussé sur SVN, il faut donc faire un roolback et un nouveau commit puis pousser, soit:
Dans la folie du commit avec ammend , j'ai aussi essayé un revert qui m'a mis dans cette position : HEAD/master, et origin/trunk décalé alors que je voulais garder la version d'origine
123456789101112131415
$ git log --all --graph --color --name-status --format='%C(yellow)%h%Creset %cr %C(blue)%cn%Creset -%C(auto)%d%Creset %s'
* 95c473c 27 hours ago j_pal - (HEAD -> master) A second fix
|
| M PROJECT/Fixes/Restore/restore.ksh
| M PROJECT/Fixes/Restore/README.txt
* 95c473c 27 hours ago j_pal - (origin/trunk) My Fix
|
| M PROJECT/Fixes/Restore/restore.ksh
| M PROJECT/Fixes/Restore/README.txt
* ed5f1f3 2 days ago j_pal - Restore script
|
| A PROJECT/Fixes/Restore/restore.ksh
| A PROJECT/Fixes/Restore/README.txt
|
...
Il fallait donc revenir à un commit ou Head, master et origin pointé sur le même commit:
1
git reset --hard origin/trunk
Questions
Pourquoi git remote -v ne me renvoie rien?
Je ne sais si vous savez contacter moi…
/!\ REGLES A RESPECTER - RAPPEL
git svn NE PAS partager/interrargir avec un autre repo git, toujours repasser par le repo SVN
Garder son historique le plus linéaire possible (rebase est ton ami)
Nous, artisans développeurs, travaillons tous avec du vieux code souvent obscur, sans intention explicite, et surtout non testé.
La question qui se pose est comment le maintenir, le faire évoluer sans risque, et aussi le remanier (refactorer en franglais).
Le code existant ou vieux code est aussi appelé “Legacy code”, ce terme a été introduit par Michael Feathers. La traduction de ‘Legacy’ n'est pas si évidente, on entend beaucoup le mot héritage mais ce n'est pas bon. ‘Legacy’ n'est pas à prendre dans le sens d'héritage, mais bien de dette. On parle donc de dette technique (“Technical Debt” par Ward Cunningham).
Alors comment modifier un code issue de la dette technique qui n'a pas de tests ?
Une première idée serait d'écrire les tests à partir des spécifications (specification tests). Or dans cette approche on va mettre en avant surtout ce que doit faire le code ou ce qu'il ne fait pas…
Mais est-ce que la spécification est à jour? Or si on veut être pragmatique, le service rendu par le logiciel est celui fait par le code et non celui écrit dans la spécification. Ici on considère que le code existant est à priori correct dans ce qu'il fait. Et donc en l'absence de test, toutes modifications de code ne doivent pas dénaturer le comportement du logiciel.
Alors comment faire?
Il faut commencer par écrire des tests qui sont représentatifs du comportement du code actuel. On dit que l'on cherche à caractériser le code.
On va donc écrire des tests de caractérisation characterization tests. A partir de ces tests qui passent, on peut donc modifier/refactorer le code avec un filet de sécurité. Si la modification laisse le test vert, on peut continuer, rien n'est cassé.
Lire le code testé va servir non pas pour acquérir la compréhension de ce qu'il fait, mais à comprendre quoi tester.
Choisir un bout de code
Ecrire un test qui échoue (rouge)
Le résultat retourné va servir de référence, on a une caractérisation \o/
Modifier le test en conséquence, le test passe au vert
Répéter
Chouette mais on répète la boucle combien de fois avant de modifier le code ?
Faire varier le(s) paramètre(s) pour obtenir plus de résultats, en s'aidant des branches de condition
Avec un outil de couverture de code on peut trouver d'autres valeurs de paramètre afin d'augmenter la couverture
=> en peu de temps on doit pouvoir obtenir 100%
=> On peut aussi faire une approche ‘Golden Master’. Cette approche consiste à dupliquer la portion de code (méthode/classe) elle devient la référence. On recode et on compare ce qu'on fait avec le code de référence –> on doit avoir le même résultat.
A cette étape nous avons une meilleur compréhension de ce que fait le code grâce à la variation des paramètres et la lecture des branches de condition pour obtenir cette couverture.
