Gitflow: La fusion des corrections de bogues de version revient à développer à partir du master

Question

Ma question tourne autour d'un point très spécifique dans le processus gitflow (comme documenté here).

J'ai déjà fusionné les corrections de bogues de release/1.2 en master, et étiqueté de manière appropriée.

En plus de l'aspect de l'historique, quelles sont les différences entre la fusion arrière de release/1.2 et la fusion inverse de master en develop.

J'ai essayé dans les deux sens, et dans mon exemple simple, artificiel, je ne vois aucune différence dans develop, comme je m'y attendais.

Y a-t-il des dangers à cela? Est-ce que je vais rencontrer des problèmes désordonnés plus tard? Est-ce que je manque quelque chose d'évident? Je soupçonne que la réponse peut être à faire avec d'autres fonctionnalités qui sont allées dans master, mais qui devrait rester sur develop pour le moment.

fusion libération pour développer:

maître fusion pour développer:

Answer 1

Si vous fusionnez master de nouveau dans votre développement, vous aurez toutes les merge branch release/x.y into master fusionner commet dans votre branche développer, tandis que quand fusionnant la branche release/x.y elle-même, vous obtenez seulement les vrais changements.

Bien sûr, c'est plus ou moins un problème esthétique. Mais la direction de fusion est habituellement seulement de develop à master, jamais l'inverse.

Il n'y a pas de réel danger, à l'exception du fait que la fusion réussit à encombrer votre branche develop. Si vous respectez le flux, il ne devrait jamais y avoir de fonctionnalités dans master qui ne sont pas dans develop, car les correctifs à chaud ainsi que les branches de publication doivent toujours être fusionnés dans votre develop ainsi que dans master.

Answer 2

Je soupçonne que la réponse est peut-être à voir avec d'autres caractéristiques qui sont allés dans master, mais qui devrait rester hors de develop pour le moment.

Validations de master vont dans develop avec prochain correctif de fusion de toute façon. S'il y avait un changement de code réel, cela pourrait être un résultat inattendu et fausser le contenu du hostfix.

La fusion de la branche stable (master dans gitflow) en branche de développement (develop dans gitflow) est connue dans divers flux de travaux git. Bbitbucket Server (solusion commerciale étant vendu par Atlassian) a une caractéristique de Automatic branch merging. Le projet Git lui-même fusionne toujours la branche maint en master car il y a quelques corrections de bogues. Donc, je ne vois pas vraiment la raison pour laquelle l'auteur de gitflow a choisi un autre moyen. Il se pourrait qu'il n'y ait pas de véritable raison, ce n'était qu'une décision accidentelle.