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. Ces branches de refactoring se terminent par des pull-request qui sont fusionnées develop. Ma question est de savoir où les branches de refactoring appartiennent à GitFlow ?

L'utilisation du featurepréfixe semble la plus logique, mais cela ne semble pas tout à fait correct, car le refactoring n'ajoute aucune nouvelle fonctionnalité.
Cependant, utiliser le bugfixpréfixe ne semble pas correct et il n'y a pas de correctifs de refactorisation de bogues 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.

— AMA
source

Pourquoi avez-vous besoin d'une succursale pour les refacteurs? Ils ne modifient pas la fonctionnalité du produit par définition, vous devriez donc pouvoir les faire directement en développement.

— jonrsharpe

@jonrsharpe en bref, c'est plus pratique et contrôlable. Il y a généralement un ticket Jira pour le refactoring et il est également révisé par code lors de la demande de pull. De plus, des builds et des tests sont exécutés pour celui-ci, avant sa fusion. Nous essayons de continuer à développer la branche verte.

— AMA

Vous êtes trop d'ingénierie - dans ce cas, le processus. Refactorisez en tant que vous travaillez sur le système, et non en tant que lot de travaux discret.

— M. Cochese

Dans ce cas: 1. Vous avez mes sympathies; et 2. Je dirais utiliser refactor, alors il est clair quelle transformation chaque fusion est censée faire pour le produit (correction de bogue: correction d'un comportement défectueux, fonctionnalité: ajout d'un nouveau comportement, refactorisation: conservation du comportement précédent). Mais @MrCochese a raison, cela devrait vraiment faire partie des autres travaux que vous ne faites pas séparément. Notez également que si vos refactors cassent la version, ils ne sont pas des refactors!

— jonrsharpe

Une partie du travail de refactorisation que vous effectuez devrait vraiment faire partie du travail principal proprement dit. Je ne ferais certainement pas de refactorisation de branches régulièrement, mais uniquement dans le cadre d'un effort de nettoyage plus important. En faire une habitude encouragera d'autres mauvaises habitudes, comme le report du travail de nettoyage à la branche «refactor».

— Robert Harvey

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 du 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

— Ewan
source

Merci. Cela semble raisonnable. J'attendrai un peu plus et s'il n'y a pas d'autres réponses, j'accepterai la vôtre.

— AMA