Git flow – se débarrasser d'une caractéristique particulière

J'essaie actuellement de mettre en place un process de développement dans mon équipe et de lire sur GitFlow. Cela semble intéressant, mais je peux repérer quelques problèmes.

Supposons le scénario suivant:

Nous finissons les fonctions F1 , F2 et F3 , et les fusionnons dans la twig de develop . Sur cette base, nous créons une twig de release .

Que pourrions-nous faire si nous voulons nous débarrasser de la fonctionnalité F3 ?

Jetez un oeil à cette image pour avoir une meilleure idée.

entrez la description de l'image ici

Solutions Collecting From Web of "Git flow – se débarrasser d'une caractéristique particulière"

C'est en effet une faiblesse de git-flow. Comme je le vois, il existe plusieurs façons d'aborder ce problème, dont aucune n'est parfaite.


Fonctionnalité rétablir

Une façon serait de simplement revert le commit de fusion de F3.

 git checkout <release-branch> git revert --mainline 1 <hash-of-f3-merge-commit> 

--mainline 1 (short -m 1 ) dit à git de rétablir les modifications du commit de fusion par rapport à son premier parent, qui est la twig dans laquelle les modifications ont été fusionnées. Dans notre cas, cela serait develop .

D'un autre côté, cela conduira à des problèmes lorsque vous mergeez la twig de release dans develop , car cela mergea également le return. Vous devrez probablement recomposer la fonctionnalité (F3) en develop .

Autre base de publication

Cette approche base votre twig de publication sur le dernier état de master au lieu de develop .

 git checkout -b master <release-branch> 

À partir de là, vous pouvez cherry-pick chaque fonctionnalité que vous souhaitez inclure dans la version. Encore une fois en utilisant l'option --mainline .

 git cherry-pick --mainline 1 <hash-of-f1-merge-commit> git cherry-pick --mainline 1 <hash-of-f2-merge-commit> 

Alternativement, vous pouvez merge les twigs de fonctionnalité dans la twig de publication au lieu de cherry-pick , ce qui aboutira au même résultat mais dans un historique plus encombré (ceci peut être évité en utilisant l'option --squash suivie d'un git commit , mais alors vous avez effectivement fait un cherry-pick ).

 git merge F1 git merge F2 

L'approche de base de version alternative n'est pas si mauvaise si chaque version ne contient qu'un petit sous-set des fonctionnalités développées, mais est difficile à utiliser si vous voulez libérer un grand nombre de fonctionnalités.


Personnellement, je préfère la dernière approche car elle se traduit par un historique plus propre sans returns et des commits de fusion en double.