Jak efektywnie wykorzystać git-flow w projekcie, w którym utrzymywana jest więcej niż jedna główna wersja?

Przeprowadziłem migrację kilku moich projektów do przepływu pracy Git Flow i uwielbiam to. Nie znalazłem jednak najlepszej praktyki, która sprawiałaby, że wszystko płynęło tak płynnie podczas pracy z projektem, w którym jednocześnie przechowywana jest więcej niż jedna główna wersja.

W szczególności nie utrzymuję „wersji bezpłatnej” i „wersji płatnej” ani żadnego innego modelu równoległego, mówię o projekcie, w którym wersja 1 zostaje wydana i pozostaje obsługiwana w mniejszych wersjach (1.1, 1.2 itd.) .) do czasu wydania wersji 3, w której utrzymane będą punkty 2 i 3, do wydania 4 ... masz pomysł.

W jaki sposób utrzymujesz dwie lub więcej obsługiwanych wersji projektu jednocześnie w przepływie pracy gitflow?

git workflows gitflow

— HedgeMage
źródło

Nie mam żadnych przykładów bankomatów, ale projekty, które znam, używały osobnych repozytoriów dla różnych głównych wersji i łatek backport od jednej do drugiej.

— ProdigySim

@ProdigySim: Dziękuję za punkt danych, ale czy to tylko ja, czy dodałoby to pewną część kosztów ogólnych do śledzenia i zarządzania?

— HedgeMage

@ProdigySim Podejrzewam, że te projekty nie używały narzędzia z funkcjami rozgałęziania i łączenia git.

— Rein Henrichs,

@ Rein Używają Mercurial. Nie sądzę, aby rozgałęzienia byłyby bardzo czyste pod względem śledzenia równoległych głównych wersji oprogramowania.

— ProdigySim

Więc moje podejrzenia były słuszne. I tak, jest całkiem czysty, jeśli twoje narzędzie obsługuje go poprawnie. git i jądro Linuksa robią to w ten sposób.

— Rein Henrichs,

Odpowiedzi:

man gitworkflows, wielki tata przepływu pracy „git flow”, opisuje ogólne wytyczne dotyczące przepływu pracy git; stosowanie pu, next, masteri maintoddziałów; i jak maintjest zarządzany. Jeśli masz wiele oddziałów konserwacji, można je wymienić, na przykład maint/1.x, maint/2.xi tak dalej.

Kluczem jest nie tyle, jak korzystać z poleceń git, ale jak zbudować rozsądny proces. Zdecyduj, co jest dla Ciebie ważne (łatwość backportowania?), I utwórz (i udokumentuj) przepływ pracy, który spełnia te ograniczenia.

— Rein Henrichs
źródło

Ale czy to odpowiada na pytanie? Mianowicie, czy git-flow obsługuje model elastycznego wydania opisany w pytaniu, czy też powraca do podstawowych poleceń git? („gitworkflows” opisuje podstawowe użycie przepływu pracy git, pre-git-flow). Git-flow został stworzony (rzekomo) w celu uproszczenia procesów scalania / rozgałęzienia git, więc zespoły (o różnym stopniu sprawności git-fu) mogą skupić się na kodowaniu i unikaj czasochłonnych błędów związanych z „błędnym połączeniem”. Czy jest możliwe w / git-flow utrzymanie i rozwój wersji 1.2. {1,2,3, ..} w tym samym czasie co wersji 2.5. {1,2,3, ...}? Być może w / oddziały długoterminowego wydania? Lub master1, master2, ...?

— Michael

Zasadniczo, byś powielać master, releaseoraz developoddziały w każdym większym wersji, którą utrzymujemy. Ich interakcja pozostaje taka sama. Na featuregałęziach, po prostu upewnij się, że oddział z najstarszych gałęzi, którą zamierzasz scalić z powrotem do , co uniemożliwia pociągnięcie do niepożądanych zależności. Następnie, gdy ponownie połączysz swój featureoddział, po prostu wykonasz dodatkowe scalenia w każdym odpowiednim nowszym głównym oddziale wersji.

— Karl Bielefeldt
źródło

Czy nie ma sensu uwzględniać każdej wydanej wersji?

— HedgeMage

@HedgeMage, w tym bardziej liniowym cyklu wydawania, ale jest to bardzo niepraktyczne dla równoległych głównych wersji.

— Karl Bielefeldt

To wydaje się być najbardziej praktycznym rozwiązaniem, chyba że istnieje jakaś sprawdzona sztuczka z użyciem poprawek lub taka, o której nie jestem świadomy. Szukałem sposobu na wprowadzenie git-flow i nadal mogę (jako niefortunny warunek) zachować nasz obecny model wydania, w którym musimy utrzymywać / rozwijać starsze wydania (nie tylko poprawki). Tak więc wersja 5.1.x pozostanie (w / dodane nowe funkcje, naprawione błędy itp.) Kilka lat po wydaniu wersji 6.1.x. W danym momencie obsługiwanych i rozwijanych jest około 2-3 główne wersje. Ale poprawki błędów należy zastosować do każdej wersji, w której występuje błąd.

— Michael