Jak postępować zgodnie z git-flow, jak poradzić sobie z poprawką wcześniejszej wersji?


101

Jeśli spróbujesz zastosować model rozgałęziania git-flow, udokumentowany tutaj i z narzędziami tutaj , jak powinieneś sobie z tym poradzić:

Stworzyłeś wersję 1.0 i wersję 2.0. Następnie musisz zrobić poprawkę dla 1.0. Tworzysz gałąź poprawki ze znacznika 1.0 i tam wdrażasz poprawkę. Ale co wtedy?

Normalnie można by scalić do mastera i umieścić tam tag wydania 1.1. Ale nie możesz scalić 1.1 do punktu po 2.0 na master.

Myślę, że można by umieścić tag wydania w gałęzi poprawki, ale to stworzyłoby stałą gałąź obok wzorca, która zawierałaby tag wydania. Czy to właściwy sposób?


możliwy duplikat Git-flow i mastera z wieloma równoległymi gałęziami wydania [chociaż drugie pytanie jest nowsze, ma bardziej przydatne odpowiedzi, więc oznaczyłem to pytanie jako zduplikowane]
danio

Odpowiedzi:


74

Wygląda na to, że w git flow istnieje koncepcja gałęzi "wsparcia". Służy do dodawania poprawki do wcześniejszej wersji.

Ten wątek zawiera więcej informacji , z następującymi przykładami:

git checkout 6.0
git checkout -b support/6.x
git checkout -b hotfix/6.0.1

... napraw, a następnie:

git checkout support/6.x
git merge hotfix/6.0.1
git branch -d hotfix/6.0.1
git tag 6.0.1

lub za pomocą git flowpoleceń

git flow support start 6.x 6.0
git flow hotfix start 6.0.1 support/6.x

... wprowadź zmiany:

git flow hotfix finish 6.0.1

? zachowaj te gałęzie wsparcia lub usuń je po pewnym czasie
Evan Hu

@EvanHu dobrze, na pewno trzymaj je tak długo, jak długo masz gdzieś tę gałąź produkcji. Potem jest to kwestia zapisu historycznego. Możesz chcieć wiedzieć, w jaki sposób poprawki zostały naprawione, jeśli kiedykolwiek miałyby się powtarzać.
Klas Mellbourn

Należy wydać wydanie poprawki, prawda? Jak możemy to zrobić?
Ravindranath Akila

33

Interesujące pytanie! Przepływ, który łączysz, zakłada, że ​​master może śledzić produkcję. Działa to tylko wtedy, gdy liczba wersji produkcyjnych jest coraz większa. Zwykle dotyczy to witryny internetowej, która ma tylko jedną wersję produkcyjną.

Jeśli musisz utrzymywać wiele wersji produkcyjnych, jedna gałąź do śledzenia produkcji nie wystarczy. Rozwiązaniem nie jest używanie wzorca do śledzenia produkcji. Zamiast tego należy użyć oddziałów podoba release1, release2itp

W tym podejściu możesz nawet nie potrzebować gałęzi poprawek. Możesz rozwiązać problem na release1gałęzi. Gdy poprawka będzie wystarczająco dobra, utwórz release1.1tag na release1gałęzi.


Możesz zmienić git-flow na ustawienie tagów wydania w gałęziach wydania. To dość duża zmiana. Zepsuje obecne skrypty. Co zatem zawierałby mistrz?
Klas Mellbourn

3
git-flowOprzyrządowanie nie jest odpowiednia, jeśli masz do obsługi wielu wersjach produkcyjnych. W przepływie pracy zaproponowanym w tej odpowiedzi wzorzec nie jest w ogóle używany. Mógłbyś nazwać master gałęzi rozwoju, w końcu to tylko nazwa.
Andomar

GitFlow obsługuje śledzenie więcej niż jednej wersji produktu: gitversion.readthedocs.io/en/latest/git-branching-strategies/ ...
Andre L

7

git-flow zakłada, że ​​obsługujesz tylko jedną linię wydania na raz, wygodnie śledzoną przez master. Jeśli utrzymujesz więcej niż 1, będziesz musiał zmodyfikować proces git-flow, aby mieć wiele trackerów oddzielnych wydań, które obsługujesz (master-1, master-2). Możesz nadal używać mastera do śledzenia najnowszej linii wydania, oprócz lub zamiast określonego trackera dla najnowszej linii wydania (master zamiast master-2).

Niestety, wszelkie narzędzia git-flow, których możesz używać, będą prawdopodobnie wymagały modyfikacji, ale miejmy nadzieję, że znasz wystarczająco proces git-flow, aby obsłużyć ten konkretny przypadek bezpośrednio za pomocą poleceń git.


Jeśli zmodyfikujesz git flowproces, będzie to coś innego. Jeśli jakiś model powinien zostać naprawiony (a nie tylko rozszerzony), to jest tak skuteczny, jak twierdzi jego autor. Zapraszam do zapoznania się z moją odpowiedzią na omawiany przez nas temat.
Victor Yarema

0

git config --add gitflow.multi-hotfix true To polecenie wydaje się działać!

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.