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

101

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?

git branch git-flow hotfix Klas Mellbourn
la source
duplication possible de Git-flow et master avec plusieurs branches de version parallèles [bien que l'autre question soit plus récente, elle a des réponses plus utiles, j'ai donc signalé cette question comme dupliquée]
danio

Réponses:

74

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
Klas Mellbourn
la source
? conserver ces branches de support ou les supprimer après un certain temps
Evan Hu
@EvanHu, bien sûr, gardez-les aussi longtemps que vous avez cette branche en production quelque part. Après cela, c'est une question d'histoire. Vous voudrez peut-être savoir comment les correctifs ont été corrigés s'ils devaient se reproduire.
Klas Mellbourn
On devrait faire une version sur le correctif, non? Comment pouvons-nous faire cela?
Ravindranath Akila le
33

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.

Andomar
la source
Vous pouvez modifier git-flow pour définir les balises de version sur les branches de version. C'est un changement assez important. Cela briserait les scripts actuels. De plus, que contiendrait alors le maître?
Klas Mellbourn
3
L' git-flowoutillage n'est pas adapté si vous devez prendre en charge plusieurs versions de production. Dans le workflow proposé dans cette réponse, le master n'est pas du tout utilisé. Vous pouvez nommer le maître de la branche de développement, ce n'est qu'un nom, après tout.
Andomar
GitFlow prend en charge le suivi de plus d'une version de production: gitversion.readthedocs.io/en/latest/git-branching-strategies
Andre L
7

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.

Bert F
la source
Si vous modifiez le git flowprocessus, ce sera quelque chose de différent. Si un modèle doit être corrigé (pas seulement étendu), il réussit aussi bien que son auteur le déclare. Veuillez consulter ma réponse au sujet dont nous discutons.
Victor Yarema
0

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

Laila
la source