Ce n'est pas master qu'il faut merge dans dev, mais le hotfix qui a atterrit sur master. Le problème étant qu'on ne peut pas vraiment mettre en place un githook sur github, à part peut-être via un webhook qui déclencherait alors un script…
C'est ce que je dis depuis le début : il faut qu'on se mette à merger à la main. C'est à dire ? On a la hiérarchie suivante :
| ---- (prod)
/
--------- (master)
/
/
/
/
----------- dev)
|
On a donc un problème : dev est carrément désynchronisé avec master, et pareil master vis à vis deprod (car il y a potentiellement eu des hotfix sur la prod).
Imaginons, je veux faire un hotfixe sur la prod. Nommons la branche du hotfix "hotfix-1".
| - (hotfix-1)
/
---- (prod)
/
--------- (master)
/
/
/
/
----------- dev)
|
en mergeant le hotfix dans prod, on a donc cet arbre :
| - (hotfix-1)
/ |
----. (prod)
/
--------- (master)
/
/
/
/
----------- dev)
|
Maintenant que la prod intègre le hotfix, il faut aussi le répercuter sur master, du coup un des mainteneurs principaux fait un merge via git checkout master; git merge hotfix-1, et pareil en répercutant aussi sur dev. Ce qui nous fait l'arbre suivant :
| - (hotfix-1)
/ |
----. (prod)
/ \
---------. (master)
/ |
/ |
/ -----
/ /
-----------. dev)
|
Le cas est évidemment le même si un fix arrive sur master, il faut aussi le répercuter sur dev.
Ceci nous permet d'avoir des arbres dit cleans, sans avoir des merge dans tous les sens, auquel cas plus rien n'est compréhensible (je sais de quoi je parle, j'ai du fixer un putain d'arbre au boulot pas plus tard qu'hier soir à cause de merges intempestifs…).
Il ne faut pas avoir peur des conflits. Il ne faut pas non plus fixer les bugs en solitaire lors d'une PR, spécialement si ça n'a rien à voir avec la feature qui est développée. De toutes façons, même en mergeant plus tard master dans dev, ou etc, on aura quand même ces même conflits, sur une échelle plus grande, auquel cas il est impossible de s'en démeler sans une boîte entière d'aspirine.
Evidemment, ce workflow (qui est du git-flow, j'anticipe…) demande un peu de rigueur, en demandant que dev, master, ou prod n'accueille que des commits de merge. Pas de commits unitaires qui se baladent. Sinon c'est un peu plus chiant, et faut jouer avec du cherry-pick.
Ainsi, si on veut mettre à jour la branche de prod pour qu'elle puisse démarrer depuis un autre point, il suffit de scratcher la branche via un git branch -D prod et la recréer au bon endroit (je parle pas de rebase ou autre, car je sais que vous y êtes allergiques) via un git checkout -b prod origin/master par exemple (ou tout identifiant de commit, de tag, … peu importe).
?
