Gitflow: git-flow « tag » emplacement de validation à la fin de la version

Créé le 30 sept. 2015 · 4Commentaires · Source: nvie/gitflow

D'après ce que j'ai compris de la page http://nvie.com/posts/a-successful-git-branching-model/ , où j'ai appris pour la première fois le modèle git-flow il y a environ 2 ans, un tag serait toujours sur le commit où la branche release a été fusionnée avec master .

J'ai récemment installé le plugin git-flow pour les extensions Git et le tag est appliqué au dernier commit sur la branche release et non sur le commit fusionné sur le master branche.

Est-ce un bug ? Est-ce vraiment important sur lequel se trouve le tag ? Ma solution de contournement est un processus manuel consistant à supprimer le tag et à le recréer là où j'ai appris à le créer.

Source

RoLYroLLs

👍5 👎1

Commentaire le plus utile

D'après ce que j'ai compris, placer la balise sur la branche de publication avant de fusionner (et non sur la branche principale) est en fait la bonne chose à faire, elle peut donc être trouvée par git describe --tags partir de la branche de développement également. Voir #374

knox le 16 mars 2016

👍6

Tous les 4 commentaires

Je viens de rencontrer le même problème avec la même compréhension que vous avez @RoLYroLLs. Voici une citation de l'article :

Lorsque l'état de la branche de version est prêt à devenir une version réelle, certaines actions doivent être effectuées. Tout d'abord, la branche de publication est fusionnée dans master (puisque chaque commit sur master est une nouvelle version par définition, rappelez-vous). Ensuite, ce commit sur master doit être étiqueté pour une référence future facile à cette version historique.

J'espère que cela sera corrigé, car je dois faire la même suppression et recréer la danse que vous avez mentionnée.

gligoran le 14 oct. 2015

Ok, j'ai joué un peu avec ça et j'ai trouvé comment le "réparer", si vous voulez, à la méthodologie écrite sur http://nvie.com/posts/a-successful-git-branching-model/.

J'ai l'impression que ce projet a été abandonné depuis la dernière fois qu'il a été touché en 2012, donc je ne créerai pas de RP, mais je laisserai ce problème actif.

Cependant, pour ceux d'entre vous comme moi, vous pouvez modifier les fichiers suivants :

https://github.com/nvie/gitflow/blob/15aab26490facf285acef56cb5d61025eacb3a69/git-flow-release#L253
et
https://github.com/nvie/gitflow/blob/15aab26490facf285acef56cb5d61025eacb3a69/git-flow-hotfix#L297

Remplacez $BRANCH par $MASTER_BRANCH

RoLYroLLs le 28 nov. 2015

knox le 16 mars 2016

👍6

D'après ce que j'ai compris, placer la balise sur la branche de publication avant de fusionner (et non sur la branche principale) est en fait la bonne chose à faire, elle peut donc être trouvée par git describe --tags partir de la branche de développement également. Voir #374

C'était un argument étrange.
Les sources sont versionnées afin que vous puissiez corréler les applications déployées avec la source qui les a créées, vous déployez à partir du maître -> le maître doit être balisé.