Mon blog sur l'artisanat logiciel et l'Agilité

Software Craftmanship - Agile (fork from My Octopress Blog)

Welcome Back!

Et voilà, il m'a fallut du temps mais le blog est de retour. Qu'est ce qui m'a bloqué pendant cette année passée …

Et bien une mise à jour de Gitlab a fait que le gitlab-ci ne déployait plus les pages …

Il m'a fallut du temps et de l'énergie pour trouver! Oui 1 an c'est long mais par morceau de 30min parci parlà puis les coupures et la remise en route ou il fallait parfois reprendre tout depuis le début … En parallèle avec d'autres activités et de plus avec une priorité basse …

Mais récemment un entretien m'a permis de me remotiver sur le sujet. J'ai donc appliqué le STOP starting START finishing, sur ce sujet. Un oeil neuf et une reprise à zéro du problème, m'a permis de comprendre que suite à une mise à jour de Gitlab, le path du projet avait été réinitialisé à mon insu. Il a fallut donc juste modifier dans les “advanced settings” le path du repository comme attendu pour les Gitlab-pages. Pensant que cela venait d'octopress, j'avais aussi basculé sur Jekkyl pour voir si cela venait de Octopress, mais non, et hop une façon de plus d'apprendre quelque chose !

Voila je peaufine quelques pages header / footer … mais je peux republier mes revues de presse et d'autres choses …

A+

Mémo GIT (4ième Partie)

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). Cf. les articles précédents: mémo1, mémo2, mémo3

Cas d'utilisation

Fusion d'un commit d'un branche vers une autre

Au cours de la vie des projets, il est courrant de faire une branche de maintenance pour faire évoluer le code d'une version déja officialisée. Ensuite, il est possible (cf. épisode précédent) de faire un merge (ou rebase) de cette branche sur la branche principale (master ou trunk) afin de récupérer les corrections. Or il arrive parfois que sur la branche principale, des ‘refactors’ aient été faits rendant certains commits de la branche de maintenance obsolètes. Donc il ne faut pas les reporter sur la branche principale. Il faut donc faire une selection des commits voulus et les appliquer sur la branche principale. La commande Git magique est le cherry-pick: Workflow:

  • Sur la branche de maintenance identifier à l'aide de git log les commits (relevé le SHA-1 associé)

  • Sur la branche principale appliqué les commits

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

bash workflow
j_pal MINGW64 /c/dev/workspace/PROJECT (master)
$ git svn rebase
Current branch master is up to date.

j_pal MINGW64 /c/dev/workspace/PROJECT (master)
$ git checkout maint
Switched to branch 'maint'

j_pal MINGW64 /c/dev/workspace/PROJECT/AWN_PACAT_MNT/environment (maint)
$ git logAll
 ...
 * d3e0611 2 days ago j_pal - QC3971-lake of Consult client config
| |
| | M   PROJECT/environment/service-compile.xml
| * 15716c9 2 days ago j_pal - QC3970-NEO manuals prod error
| |
| | M   PROJECT/environment/service-build.xml
| *   f2a0ad3 3 days ago j_pal - OTH-Maintenance V3.13
 ...

j_pal MINGW64 /c/dev/workspace/PROJECT/AWN_PACAT_MNT/environment (master)
$ git cherry-pick  15716c9
[master 81e3a58] QC3970-NEO manuals prod error
 Author: j_pal <j_pal@2a9a025e-1ade-4945-b3f3-c86421e8e34f>
 Date: Wed May 31 13:19:09 2017 +0000
 1 file changed, 4 insertions(+), 4 deletions(-)

j_pal MINGW64 /c/dev/workspace/PROJECT (master)
$ git svn dcommit
Committing to https://airplfms15.sesame.com:8443/svn/PROJECT/trunk ...
        M       PROJECT/AWN_PACAT_MNT/environment/service-build.xml
Committed r2857
        M       PROJECT/AWN_PACAT_MNT/environment/service-build.xml
r2857 = 91fccb894cab4030038b010f7d1b1e1be5b45a43 (refs/remotes/origin/trunk)
No changes between 81e3a58e3f624469eb38690761d819d299b95086 and refs/remotes/origin/trunk
Resetting to the latest refs/remotes/origin/trunk

Tout est en ordre ! En cas de conflit c'est comme d'habitude mémo3

Note:

git logAll est un alias inséré dans ma config de cette façon: git config alias.logall=log --all --graph --color --name-status --format='%C(yellow)%h%Creset %cr %C(blue)%cn%Creset -%C(auto)%d%Creset %s'

/!\ 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)
  • Ne rebasez jamais des commits qui ont déjà été poussés sur un dépôt public.`

Liens et sources

Mes Butinages De La Semaine 19

Bon butinage !

Artisanat logiciel

Internet

Vie privée

Divers

Mes Butinages De La Semaine 18

Bon butinage !

Artisanat logiciel

Internet

Mes Butinages De La Semaine 17

Bon butinage !

Artisanat logiciel

Internet

Éducation - Agile

Divers

Mémo GIT (3ième Partie)

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). Cf. les articles précédents: (https://jeanpalaz.gitlab.io/blog/2017/02/01/Git-SVN-workflow/) (https://jeanpalaz.gitlab.io/blog/2017/04/26/Git-SVN-workflow2/)

Cas d'utilisation

Fusion du trunk et d'une branche SVN avec conflit

Il y a 2 façons de fusionner avec GIT avec la commande git merge ou git rebase. Je vous laisse le soin de regarder la doc afin de vous familiariser ou d'appronfondir la question. Il y a une chose à retenir c'est Ne rebasez jamais des commits qui ont déjà été poussés sur un dépôt public. – Progit : Les dangers du rebasage. Si je reprends le cas de du Memo2, nous sommes dans le cas ou nous avons une branche publique SVN (maint) et une branche publique (trunk). Donc nous allons utiliser le git merge.

1
2
3
4
5
6
7
8

j_pal MINGW64 /c/dev/workspace (master)
$ git merge maint
Auto-merging PROJECT/xsl/eipc.xsl
Auto-merging PROJECT/xsl/common/sblist.xsl
CONFLICT (content): Merge conflict in PROJECT/xsl/common/sblist.xsl
Automatic merge failed; fix conflicts and then commit the result.

j_pal MINGW64 /c/dev/workspace (master|MERGING)

Paf ! C'est le drame conflit !!! Don’t Panic ! On édite le fichier on résout le conflit classiquement. On sauve. Et on ajoute le fichier à l'index git add monFichier, c'est de cette façon que l'on résout les conflits sous GIT. Le reste devient une habitude :)

1
2
3
4
5
6
7
8

$ git commit -m "Fusssiiiiiioonnn"
[master c341143] Fusssiiiiiioonnn
j_pal MINGW64 /c/dev/workspace (master)
git svn dcommit
....
j_pal MINGW64 /c/dev/workspace (master)
git branch -d maint
Deleted branch maint (was 1e474ce).

Au passage un remarque la mention de MERGING dans le prompt qui disparait après commit.

/!\ 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)
  • Ne rebasez jamais des commits qui ont déjà été poussés sur un dépôt public.

Liens et sources