Où vont les corrections de bugs dans le modèle git-flow?
Dans le, généralement appelé Git-flow les correctifs du modèle vont dans leur hotfix-* branche et petites corrections d'intégration juste avant la sortie allez dans le release-* branche. Les corrections de bugs généraux de la version précédente ne semblent pas avoir leur place.
Où devraient-ils apparaître? Devraient-ils être dans leur propre bug-* branche dérivée de develop (comme feature branches)?
La réponse courte: Oui, les branches pour les corrections de bogues qui entrent dans une prochaine version prévue devraient être dans les branches de fonctionnalités. La façon dont vous nommez les branches de fonctionnalités ou ces branches pour les corrections de bogues dépend de vous et des normes de votre équipe, mais elles doivent être traitées de manière identique si vous suivez Gitflow.
commentaire de Bart van Ingen Schena soulève un bon point.
Gitflow a cinq types de branches: master, develop, branches de correctif (préfixées avec hotfix-), libérer les branches (préfixées par release- et les branches de fonction. Les branches master et develop sont des branches de longue durée et vous ne vous y engagez pas directement. Le release- les branches sont conçues pour tracer une ligne pour une version particulière, puis prendre en charge les corrections de bogues entre l'identification de la prochaine version et la version. Le hotfix- les branches sont spécifiquement destinées aux mises en production critiques hors cycle en production. Le feature- les branches sont destinées au développement de fonctionnalités individuelles pour une version future.
Provenant d'environnements où des RP sont utilisés et mis à part un développeur individuel qui s'engage dans une branche de fonctionnalité, rien ne doit être directement engagé dans master, develop ou une branche de publication. Cela garantit que chaque changement est révisé par le code, ainsi que la garantie d'une couverture de test appropriée et la réussite des tests dans un environnement CI avant que les changements ne soient effectués. Je n'ai aucun problème à valider des correctifs ou des modifications de bogues avant la publication directement dans la branche de publication, puis à les insérer dans le développement, puis dans les branches de fonctionnalités.
Dans votre cas particulier, un release- branch n'est pas un endroit approprié. Le logiciel est déjà sorti et se trouve dans master. Une fois qu'une version est fusionnée dans master et étiquetée à cet endroit, la branche de publication de cette version particulière a dépassé son objectif et n'a plus nécessairement besoin d'exister. Si vous êtes actif dans le nettoyage de vos succursales (ce que je pense que tout le monde devrait être), ce n'est même pas une option.
Si votre correctif n'est pas critique, une branche de correctifs ne semble pas convenir non plus. Le but d'une branche de correctifs est de permettre à quelqu'un d'obtenir des changements critiques dans la production très rapidement sans interférer avec le développement en cours. Leur utilisation devrait être l'exception plutôt que la norme pour une équipe de développement. En général, les correctifs critiques devraient être un cas exceptionnel.
La seule chose qui reste est une branche de fonctionnalité. Notez que la section de la page liée à la question sur les branches de fonctionnalité dit même que les branches de fonctionnalité sont "parfois appelées branches de sujet". Si votre modification cible une version à venir et ne répond pas aux critères d'un correctif, elle doit se trouver dans l'une de ces branches.
S'il s'agit d'une seule validation, effectuez simplement une validation bien identifiée et poussez-la au-dessus de la branche de développement, sinon créez une branche de fonctionnalité.
Il y a aussi un commentaire de l'auteur de git-flow disant exactement ce que vous demandez: Branches de correction de bogues manquantes # 24