Quelle est la place du refactoring dans le modèle de dénomination de branche GitFlow?
J'ai récemment commencé à travailler avec le modèle GitFlow tel qu'implémenté par bitbucket. Et il y a une chose qui n'est pas complètement claire pour moi.
Nous essayons de régler régulièrement notre dette technique en enregistrant, en planifiant et en mettant en œuvre les tâches de refactoring. De telles branches de refactoring se terminent par des pull-requests qui sont fusionnées dans develop. Ma question est où les branches de refactoring appartiennent-elles à GitFlow ?
- Utiliser le préfixe
featuresemble le plus logique, mais il ne semble pas tout à fait correct, car le refactoring n'ajoute aucune nouvelle fonctionnalité. - Cependant, utiliser le préfixe
bugfixne semble pas correct et il n'y a pas de correctifs de refactoring bug réels. - D'un autre côté, créer un préfixe personnalisé semble compliquer, sinon surcharger les choses.
Avez-vous eu une telle situation? Quelle pratique utilisez-vous pour résoudre ce problème? Veuillez expliquer pourquoi.
Le travail de refactorisation doit aller dans une branche de fonctionnalité.
Le préfixe "fonctionnalité" est juste un mot pour décrire une tâche de programmation discrète, vous pouvez choisir n'importe quel mot que vous aimez, n'importe quelle branche de développement est soit une branche "fonctionnalité" soit une branche "version"
L'ajout d'un nouveau préfixe tel que "refactoring" est problématique. Comme vous effectuerez souvent une refactorisation lors de l'ajout d'une fonctionnalité, vous vous posez simplement un problème de dénomination et ajoutez de la confusion. c'est à dire. "Certaines de nos branches de fonctionnalités sont appelées" refactoring ", non, elles ne contiennent pas tout le travail de refactoring et parfois elles contiennent des corrections de bogues ou des fonctionnalités"
de même, les branches "hotfix" ne sont pas appelées hotfix car elles contiennent des hotfix, mais parce qu'elles se ramifient à partir du maître plutôt que de se développer