Suite à git-flow, comment gérer un correctif d'une version antérieure?

Si vous essayez de suivre le modèle de branchement git-flow, documenté ici et avec des outils ici , comment devez-vous gérer cette situation:

Vous avez créé une version 1.0 et une version 2.0. Ensuite, vous devez créer un correctif pour la version 1.0. Vous créez une branche de correctif sur la balise 1.0 et implémentez le correctif à cet endroit. Mais quoi alors?

Normalement, vous fusionnerez dans master et y mettriez une balise de version 1.1. Mais vous ne pouvez pas fusionner 1.1 à un point après 2.0 sur master.

Je suppose que vous pourriez mettre la balise release sur la branche du correctif, mais cela créerait une branche permanente à côté du master qui contiendrait une balise release. Est-ce la bonne manière?

Il semble qu'il existe un concept de branche "support" dans git flow. Ceci est utilisé pour ajouter un correctif à une version antérieure.

Ce fil contient plus d'informations , avec ces exemples:

git checkout 6.0
git checkout -b support/6.x
git checkout -b hotfix/6.0.1

... faites votre solution, alors:

git checkout support/6.x
git merge hotfix/6.0.1
git branch -d hotfix/6.0.1
git tag 6.0.1

ou en utilisant des git flowcommandes

git flow support start 6.x 6.0
git flow hotfix start 6.0.1 support/6.x

... apportez des modifications alors:

git flow hotfix finish 6.0.1

Question interessante! Le flux que vous avez lié suppose que le maître peut suivre la production. Cela ne fonctionne que si les versions de production augmentent strictement. C'est généralement vrai pour un site Web qui n'a qu'une seule version de production.

Si vous devez gérer plusieurs versions de production, une seule branche pour suivre la production ne suffit pas. Une solution consiste à ne pas utiliser master pour suivre la production. Au lieu de cela, les branches d'utilisation aiment release1, release2etc.

Dans cette approche, vous n'aurez peut-être même pas besoin d'une branche de correctif. Vous pouvez résoudre le problème sur la release1branche. Lorsque le correctif est suffisant, créez une release1.1balise sur la release1branche.

git-flow suppose que vous ne supportez qu'une seule ligne de publication à la fois, facilement suivie par master. Si vous en maintenez plus de 1, vous devrez modifier le processus git-flow pour avoir plusieurs trackers de vos versions distinctes que vous prenez en charge (master-1, master-2). Vous pouvez continuer à utiliser master pour suivre la ligne de version la plus récente, en plus ou à la place d'un tracker spécifique pour la ligne de version la plus récente (master au lieu de master-2).

Malheureusement, tout outil git-flow que vous pourriez utiliser devra probablement être modifié, mais j'espère que vous êtes suffisamment familier avec le processus git-flow pour gérer ce cas spécifique directement avec les commandes git.

git config --add gitflow.multi-hotfix true Cette commande semble fonctionner pour moi!