113 votes

En suivant le 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 outils ici comment gérer cette situation :

Vous avez fait une version 1.0 et une version 2.0. Vous devez ensuite créer un correctif pour la version 1.0. Vous créez une branche de correctif à partir du tag 1.0 et y implémentez le correctif. Mais que se passe-t-il ensuite ?

Normalement, vous devriez fusionner vers master et y mettre une étiquette de version 1.1. Mais vous ne pouvez pas fusionner la 1.1 à un point situé après la 2.0 sur master.

Je suppose que vous pourriez mettre l'étiquette de version sur la branche hotfix, mais cela créerait une branche permanente à côté du master qui contiendrait une étiquette de version. Est-ce la bonne méthode ?

87voto

Klas Mellbourn Points 6771

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

Ce fil de discussion contient plus d'informations avec ces exemples :

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

... fais ta réparation, 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 git flow commandes

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

... faire des changements alors :

git flow hotfix finish 6.0.1

35voto

Andomar Points 115404

Question intéressante ! Le flux que vous avez lié suppose que le maître peut suivre la production. Cela ne fonctionne que si les versions de production sont strictement croissantes. C'est typiquement le cas pour un site web qui n'a qu'une seule version de production.

Si vous devez maintenir plusieurs versions de production, une branche pour suivre la production n'est pas suffisante. Une solution consiste à ne pas utiliser master pour suivre la production. Au lieu de cela, utilisez des branches comme release1 , release2 etc.

Dans cette approche, vous n'aurez peut-être même pas besoin d'une branche hotfix. Vous pouvez corriger le problème sur la branche release1 branche. Lorsque la correction est suffisamment bonne, créez une release1.1 sur l'étiquette release1 branche.

7voto

Bert F Points 27237

Git-flow suppose que vous ne supportez qu'une seule ligne de version à la fois, commodément suivie par master. Si vous maintenez plus d'une version, vous devrez modifier le processus de git-flow pour avoir plusieurs trackers pour les différentes versions que vous maintenez (master-1, master-2). Vous pouvez continuer à utiliser master pour suivre la ligne de version la plus récente, en plus ou au lieu 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 utilisez devra probablement être modifié, mais nous espérons que vous êtes suffisamment familier avec le processus git-flow pour traiter ce cas spécifique directement avec les commandes git.

-3voto

Laila Points 1

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

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X