Odpowiedni przepływ pracy Git dla wielu aktywnych wydań podczas obsługi poprawek

Próbuję wybrać przepływ pracy Git, który jest najbardziej odpowiedni dla naszego produktu. Oto parametry:

• Wydajemy kilka głównych wydań rocznie, powiedzmy najwyżej 10
• Mamy wiele wersji naszego produktu aktywnych jednocześnie (niektóre osoby korzystają z wersji 10.1, niektóre z wersji 11.2 itd.)
• Musimy być w stanie pracować nad wieloma wydaniami jednocześnie (abyśmy mogli pracować nad wersją 12.1, ale gdy zbliżamy się do końca wydania, zaczynamy pracować nad wersją 12.2 w tym samym czasie)
• Musimy mieć możliwość poprawiania wydań, gdy zostaną znalezione krytyczne błędy

Jak dotąd, myślę, że może to działać:

• Wykorzystywane jest pojedyncze zdalne repo
• Utwórz gałąź 12.1 z poziomu głównego
• Twórz gałęzie funkcji na podstawie 12.1, zatwierdzaj je i łącz z powrotem w 12.1, push
• Gdy będziemy musieli rozpocząć pracę nad przyszłym wydaniem, utwórz nowy oddział 12.2 w oparciu o 12.1
• Odtąd, pracując nad funkcją dla 12.1, utwórz gałąź z 12.1, zatwierdzaj zmiany i scalaj w 12.1 i 12.2, wypychaj
• Jeśli pracujesz nad funkcją dla 12.2, utwórz gałąź z 12.2, zatwierdź zmiany i scal tylko w 12.2, push
• Po zakończeniu wydania 12.1 połącz je w master i oznacz gałąź master za pomocą 12.1
• Jeśli potrzebna jest poprawka, utwórz gałąź poprawki z najstarszej gałęzi wydania, która jej potrzebuje, zatwierdź zmiany i ponownie połącz ze wszystkimi gałęziami wydania dla tego wydania i przyszłych wydań, na które może mieć to wpływ; jeśli dotyczy to najnowszej gałęzi stabilnego wydania, połącz ją w master.

Mam kilka obaw:

• Nie jestem pewien, czy scalanie poprawek ze starych gałęzi do nowych gałęzi będzie płynnym procesem, zwłaszcza jeśli wprowadzono wiele nakładających się zmian; czy mądrzej byłoby po prostu ręcznie wprowadzić poprawkę w każdej gałęzi w przypadkach, gdy wygląda na to, że wystąpią konflikty
• Modele przepływu pracy, które widziałem, wydają się nie utrzymywać gałęzi wydania przy życiu, po wykonaniu wydanie zostaje scalone w master, oznaczone i usunięte. Mój problem polega na tym, że nie mam dobrego pomysłu na zarządzanie stanem wydania, jeśli wszystko, co mam, to znaczniki w systemie głównym, wydaje się, że łatwiej jest je naprawić w gałęzi, a następnie mam wydanie, do którego zawsze mogę wrócić który ma najnowszą poprawkę (mogę nawet oznaczyć poprawki w wydaniu). Nie jestem pewien, czy istnieje sposób, aby wrócić do programu master i jakoś mieć kopię wydania z zastosowanymi poprawkami i zaktualizować ten tag.

Doceniam komentarze na temat rzeczy, które mogłem przeoczyć, lub lepszych sposobów realizacji rzeczy, biorąc pod uwagę określone wymagania.

Wygląda na to, że rozgałęziasz się w każdej głównej wersji (12.0.0), a następnie masz możliwe niewielkie aktualizacje każdej (12.1.0) i poprawki (12.2.1). Poprawny?

Nie ma konkretnego powodu, dla którego nie można utrzymać gałęzi wydania w GitFlow po wydaniu, poza faktem, że koordynacja zmian między wieloma rozbieżnymi gałęziami przez długi czas jest trudna w przypadku dowolnego modelu. Podejrzewam, że GitFlow był również bardziej modelowany dla produktów, które utrzymują jedno wydanie na żywo podczas opracowywania następnego.

Pozostałbym przy GitFlow i wprowadził kilka poprawek;

Pomiń gałąź główną. Do tej pory nie miałem praktycznego zastosowania i straciłoby to liniowość w trakcie pracy. Kontynuuj rozwój następnej ważnej wersji na develop. Jeśli zdecydujesz się zachować master, nie umieszczaj tagów release na master, umieść je w ostatnim zatwierdzeniu w gałęzi release, która wygenerowała wysyłany plik binarny.

Nie wyrzucaj gałęzi wydania po scaleniu ich z powrotem w celu rozwoju. Zamiast tego trzymaj je przy sobie do następnej niewielkiej wersji i możliwych poprawek. Jeśli kiedykolwiek przestaniesz obsługiwać wydanie, myślę, że można je usunąć. Możesz nazwać gałęzie wydania według ich głównego komponentu, release / 12, a następnie utworzyć gałęzie sub-release, release / 12.1, release / 12.2. Nie musiałem się zbytnio przejmować tym poziomem równoległości, ale prawdopodobnie tego właśnie spróbowałbym. W tym przypadku możesz myśleć o każdej głównej gałęzi wydania jako o własnym środowisku sub-GitFlow.

Jeśli musisz równolegle pracować nad funkcjami dla kilku przyszłych głównych wydań w tym samym czasie, być może musisz zachować kolejne (13) w fazie rozwoju i cokolwiek dla późniejszych wersji (14, 15) w dodatkowych gałęziach „develop-N” . Wydaje się to bardzo trudne do utrzymania, ale byłoby możliwe.

Wydaje się, że możliwym rozwiązaniem twojego głównego problemu ( «Musimy być w stanie pracować nad wieloma wydaniami jednocześnie [...]» )git worktree add <path> [<branch>]

Repozytorium git może obsługiwać wiele działających drzew , co pozwala na sprawdzenie więcej niż jednej gałęzi na raz.
Z git worktree addnowym drzewem roboczym jest powiązane z repozytorium.

To nowe drzewo robocze jest nazywane „połączonym drzewem roboczym” w przeciwieństwie do „głównego drzewa roboczego” przygotowanego przez „ git init” lub „ git clone” .
Repozytorium ma jedno główne drzewo robocze (jeśli nie jest to samo repozytorium) i zero lub więcej powiązanych drzew roboczych.

Zobacz tę odpowiedź SO, aby uzyskać szczegółowe wprowadzenie git worktree.

Wspomniałeś, że znasz gitflow. Sugeruję dodanie opcji do swojego scenariusza. Konieczne będzie utworzenie oddziałów z oddziału programistycznego w celu obsługi starszych wersji. Te starsze wersje będą również musiały mieć własne gałęzie wydania / główne i gałęzie poprawek. Będziesz musiał okresowo łączyć swoje oddziały wsparcia z nowymi oddziałami wsparcia i gałęzią rozwoju.

W miarę rozbieżności w rozwoju głównych wersji będzie to coraz trudniejsze. Nie ma na to srebrnej kuli. Czasami łatwiej będzie wprowadzić zmiany ręcznie. Koszt utrzymania starszych wersji wzrośnie iw pewnym momencie nie będzie już tego wart.

Wszystko zależy od tego, jakie zmiany wprowadzasz w swoich starszych wersjach. Jeśli tylko naprawienie błędów, stosunkowo łatwo je scalić. Jeśli spróbujesz dodać nowe funkcje, będzie to trudne.