Modèle de branches

Bon, tout d'abord désolé pour ceux qui ont essayé, en vain, de lire et de comprendre mes posts précédents… Maintenant je vais tenter de recommencer plus clair, plus court et plus précis

Donc tout d'abord j'approuve entièrement le workflow proposé par SpaceFox. C'est un très bon modèle qui a fait ses preuves sur une très grande quantité de projets ayant tous leur spécificité.

Sinon, pour revenir aux conflits entre dev et la branche de release.
Tout d'abord il faut savoir que à moins d'avoir énormément de bugs à corriger ce cas est relativement rare, sinon il y a plusieurs choses qui peuvent être tentés afin de transformer, si possible, le MAY du graph en MUST afin d'éviter au mainteneur (ou à un mainteneur suivant) d'avoir à résoudre le conflit lors de la fusion de la branche de release dans dev :

1
2
3
4
5
6
7

1. l'auteur cré son patch sous dans une branche bug-fix/10 basée sur la branche de release
2. On se rend compte que ça vas créer un conflit important lors de la fusion de la release dans dev
3. On demande à l'auteur du bug-fix si il est en mesure de résoudre le conflit lui même
4. Sinon, on peut eventuellement demander à celui qui a fournis le patch implémentant la ZEP qui est en conflit avec le bug-fix actuel si il est en mesure de résoudre le conflit
5. Sinon, on peut faire un appel à contribution pour demander si quelqu'un est en mesure de résoudre ce conflit
6. Sinon, si on peut attendre qu'un mainteneur à même de régler le conflit soit disponible (SpaceFox par exemple) et c'est donc lui qui ira fusionner le patch (la pull request)
7. Sinon, dans le pire des cas (c'est à dire quand personne ne peut résoudre le conflit et que l'on ne peut pas attendre) le mainteneur fusionne le patch dans la branche de release uniquement et on tombe sur le cas décrit par SpaceFox

Comment se passe la résolution du conflit par un tiers ?

1. l'auteur cré son patch sous dans une branche bug-fix/10 basée sur la branche de release
2. L'auteur, ou un autre contributeur, (on vas appeler cette personne Monsieur X) cré un nouvelle branche basée sur la branche de dev et appelée bug-fix/10-dev
3. Monsieur X fusionne la branche bug-fix/10 dans sa branche bug-fix/10-dev et résout le conflit à ce moment là
4. Il soumet sa branch sur github et notifie dans les commentaires du patch bug-fix/10 qu'il a résolu le conflit dans sa branche bug-fix/10-dev
5. Le mainteneur fusionne bug-fix/10 dans la branche de release
6. Le mainteneur fusionne bug-fix/10-dev dans la branche dev
7. Le mainteneur fusionne la branche de release dans la branche dev (à ce moment là il n'y doit y avoir, en principe, strictement aucun conflit)

Donc voilà, c'est une petite astuce qui, assumant que la personne la mieux à même de résoudre les conflits est souvent l'auteur du patch, d'essaye d'éviter autant que possible au mainteneur d'avoir à assumer cette tâche.

J'espère que maintenant c'est plus clair.

P.S Je me permet quand même au passage de redire se que SpaceFox a dit : en pratique c'est un point qui est relativement rare. En réalité ça ne peut vraiment se présenter que dans 2 cas :

1. La branche de realease a une durée de vie extrèmement longue (plus c'est plus plus ça a de chances d'arriver)
2. Un patch effectuant des changement vraiment très très lourd a été fusionné dans dev après la création de la branche de release et, avant le changement de release, un bug a été découvert sur la pré-prod.
   Ca peut arriver, mais en pratique, si on sait que la durée de vie de la branche de release est faible il est parfois meilleur d'attendre sa fin de vie pour fusionner les plus gros patchs

EDIT: Finallement c'est pas plus court, désolé… mais par contre ça devrait être beaucoup plus clair.