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

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?

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

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.

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.

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