Wohin gehört das Refactoring im GitFlow-Zweigbenennungsmodell?

Ich habe kürzlich angefangen, mit GitFlow-Modellen zu arbeiten, die von bitbucket implementiert wurden. Und eines ist mir nicht ganz klar.

Wir versuchen, unsere technischen Schulden regelmäßig zu beheben, indem wir die Refactoring-Aufgaben zurückbuchen, planen und umsetzen. Solche Umgestaltungszweige enden mit Pull-Requests, die zusammengeführt werden develop. Meine Frage ist, wohin die Refactoring-Zweige in GitFlow gehören .

Die Verwendung des featurePräfixes erscheint am logischsten, fühlt sich jedoch nicht ganz richtig an, da durch das Refactoring keine neuen Funktionen hinzugefügt werden.
Die Verwendung des bugfixPräfixes scheint jedoch nicht richtig zu sein, da es keine tatsächlichen Fehlerbehebungen für das Refactoring gibt.
Das Erstellen eines benutzerdefinierten Präfixes hingegen scheint die Dinge zu komplizieren, wenn nicht sogar zu überentwickeln.

Hattest du eine solche Situation? Mit welcher Praxis sprechen Sie dies an? Bitte erklären Sie warum.

— AMA
quelle

Warum brauchen Sie überhaupt eine Filiale für Refactors? Sie ändern per Definition nicht die Funktionalität des Produkts, sodass Sie sie direkt in der Entwicklung ausführen können sollten.

— jonrsharpe

@jonrsharpe kurz, es ist bequemer und kontrollierbar. Es gibt normalerweise ein Jira-Ticket für das Refactoring und es wird auch während der Pull-Anfrage überprüft. Außerdem werden Builds und Tests dafür ausgeführt, bevor es zusammengeführt wird. Wir versuchen, den Zweig grün zu halten.

— AMA

Sie übertreiben Dinge - in diesem Fall den Prozess. Refactor als Sie als Arbeit am System, nicht als diskretes Arbeitspaket.

— Mr Cochese

In diesem Fall: 1. Sie haben mein Mitgefühl; und 2. Ich würde sagen, verwenden refactor, dann ist klar, welche Transformation jede Zusammenführung mit dem Produkt bewirken soll (Bugfix: Beheben eines fehlerhaften Verhaltens, Feature: Hinzufügen eines neuen Verhaltens, Refactor: Beibehalten des vorherigen Verhaltens). Aber @MrCochese ist richtig, es sollte wirklich ein Teil der anderen Arbeit sein, die Sie tun, keine separate Aufgabe. Beachten Sie auch, dass Ihre Refaktoren keine Refaktoren sind

— jonrsharpe

Einige der Refactoring-Arbeiten, die Sie durchführen, sollten wirklich Teil der eigentlichen Hauptarbeit sein. Ich würde Refactor-Zweige sicherlich nicht routinemäßig erstellen, sondern nur im Rahmen eines größeren Aufräumvorgangs. Wenn Sie dies zur Gewohnheit machen, werden andere schlechte Gewohnheiten gefördert, z. B. die Verschiebung von Aufräumarbeiten auf den Zweig "Refactor".

— Robert Harvey

Refactoring-Arbeiten sollten in einem Feature-Zweig durchgeführt werden.

Das Präfix "Feature" ist nur ein Wort zur Beschreibung einer diskreten Programmieraufgabe. Sie können ein beliebiges Wort auswählen. Jeder Zweig aus der Entwicklung ist entweder ein "Feature" -Zweig oder ein "Release" -Zweig

Das Hinzufügen eines neuen Präfixes wie "Refactoring" ist problematisch. Da Sie beim Hinzufügen eines Features häufig einige Umgestaltungen vornehmen, geben Sie sich lediglich ein Namensproblem und sorgen für Verwirrung. dh "Einige unserer Feature-Zweige werden als" Refactoring "bezeichnet. Nein, sie enthalten nicht die gesamte Refactoring-Arbeit und enthalten manchmal Fehlerbehebungen oder Features."

In ähnlicher Weise werden "Hotfix" -Zweige nicht als Hotfix bezeichnet, weil sie Hotfixes enthalten, sondern weil sie eher vom Master als von der Entwicklung abzweigen

— Ewan
quelle

Danke. Das klingt vernünftig. Ich werde noch ein bisschen warten, und wenn es keine anderen Antworten gibt, werde ich Ihre annehmen.

— AMA