Gdzie refaktoryzacja należy do modelu nazewnictwa gałęzi GitFlow?

22

Niedawno zacząłem pracować z modelem GitFlow zaimplementowanym przez bitbucket. I jest jedna rzecz, która nie jest dla mnie całkowicie jasna.

Staramy się regularnie rozwiązywać nasze problemy techniczne poprzez zaległości, planowanie i wdrażanie zadań refaktoryzacyjnych. Takie oddziały refaktoryzacji kończą się połączonymi żądaniami typu pull develop. Moje pytanie brzmi, gdzie należą oddziały refaktoryzacji w GitFlow ?

  • Używanie featureprzedrostka wydaje się najbardziej logiczne, jednak nie wydaje się całkowicie poprawne, ponieważ refaktoryzacja nie dodaje żadnej nowej funkcjonalności.
  • Jednak używanie bugfixprefiksu wydaje się niewłaściwe, ponieważ nie ma faktycznych poprawek refaktoryzacji błędów.
  • Z drugiej strony, tworzenie niestandardowego przedrostka wydaje się skomplikowane, jeśli nie nadmiernie inżynierskie.

Czy miałeś taką sytuację? Jakiej praktyki używasz, aby rozwiązać ten problem? Proszę wyjaśnić dlaczego.

git  refactoring  branching  gitflow 
— AMA
źródło
Dlaczego w ogóle potrzebujesz oddziału dla refaktorów? Z definicji nie zmieniają funkcjonalności produktu, więc powinieneś być w stanie to zrobić bezpośrednio w fazie rozwoju.
— jonrsharpe
@jonrsharpe w skrócie, jest to wygodniejsze i łatwiejsze do kontrolowania. Zwykle do refaktoryzacji jest bilet Jira i jest on również poddawany przeglądowi kodu podczas żądania ściągnięcia. Ponadto uruchamiane są dla niego kompilacje i testy, zanim zostaną scalone. Staramy się rozwijać gałąź zieloną.
— AMA
4
Nadmiernie ingerujesz w sprawy - w tym przypadku proces. Dokonuj refaktoryzacji podczas pracy w systemie, a nie jako dyskretny pakiet roboczy.
— Pan Cochese,
2
W takim przypadku: 1. Masz moje współczucie; i 2. Powiedziałbym użycie refactor, wtedy jasne jest, jaką transformację ma wykonać każde scalenie produktu (poprawka: naprawi zepsute zachowanie, funkcja: dodaj nowe zachowanie, refaktoryzuj: zachowaj poprzednie zachowanie). Ale @MrCochese ma rację, to naprawdę powinna być część innej pracy, którą wykonujesz, a nie oddzielne zadanie. Zauważ też, że jeśli twoi refaktorzy zepsują kompilację, nie są refaktorami!
— jonrsharpe
Niektóre z prac refaktoryzacyjnych, które wykonujesz, powinny naprawdę być częścią głównej właściwej pracy. Z pewnością nie robiłbym rutynowo gałęzi refaktorów , ale tylko w ramach większego wysiłku oczyszczania. Przyzwyczajenie się do tego zachęci innych złych nawyków, takich jak odroczenie prac porządkowych w oddziale „refactor”.
— Robert Harvey

Odpowiedzi:

27

Prace refaktoryzacyjne powinny przejść do gałęzi funkcji.

Przedrostek „funkcja” to tylko słowo opisujące dyskretne zadanie programistyczne, możesz wybrać dowolne słowo, dowolna gałąź z rozwoju to gałąź „funkcja” lub gałąź „wydanie”

Dodanie nowego przedrostka, takiego jak „refaktoryzacja”, jest problematyczne. Ponieważ podczas dodawania funkcji często dokonujesz refaktoryzacji, po prostu stwarzasz sobie problem z nazewnictwem i wprowadzasz zamieszanie. to znaczy. „niektóre z naszych gałęzi funkcji nazywane są„ refaktoryzacją ”, nie, nie zawierają one wszystkich operacji refaktoryzacji, a czasami zawierają poprawki błędów lub funkcje”

podobnie gałęzie „poprawek” nie są nazywane poprawkami, ponieważ zawierają poprawki, ale ponieważ rozgałęziają się od strony głównej, a nie rozwijają się

— Ewan
źródło
1
Dziękuję Ci. Brzmi rozsądnie. Poczekam jeszcze trochę, a jeśli nie będzie innych odpowiedzi, zaakceptuję twoje.
— AMA
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.