Fonctionnalité Gitflow vs dénomination de branche de correction de bugs
Lors de l'utilisation de Gitflow, quelle est la raison de la séparation de la dénomination de branche en fonction vs correction de bug vs correction à chaud?
C'est à dire. pourquoi pas seulement, par exemple, au lieu de:
feature/
bugfix/
hotfix/
Faites juste:
change/
Qu'achète la séparation par fonctionnalité/correction de bogue/correctif?
Les bonnes questions et la réponse dépendent vraiment de la façon dont vous triez votre git. Le modèle de branchement et gitflow en général essaient de nous donner un peu d'ordre dans le chaos qui s'engage juste après quelques jours.
L'image ci-dessous vous montre ce qu'ils ont le plus de sens.
(Pour autant que je sache, tout vient de ce blog de Vincent Driessen )
La séparation de vos correctifs qui fusionnent directement dans master et de vos correctifs qui fusionnent dans dev facilite le déroulement de votre cycle de produit.
L'idée est de créer votre application, de créer des fonctionnalités, de faire une version candidate (test bêta), puis de publier votre application. Des correctifs peuvent être nécessaires à tout moment après cela. Inutile de remonter jusqu'à la branche des fonctionnalités et d'y apporter un correctif car la fonctionnalité peut déjà avoir été développée.
Cela a-t-il du sens?
