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

30

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.

Rocket04
źródło
11
Zdaję sobie sprawę z git-flow, ale nie widzę, jak rozwiązuje to problem w przypadku wielu jednoczesnych wydań. Wygląda na to, że gałęzie wydania nie są tak naprawdę przeznaczone do pracy, głównie do czyszczenia, a następnie scalania i tagowania. Co mam zrobić, jeśli mam poprawkę, która dotyczy 4 różnych wersji? Wydaje mi się, że mógłbym pobrać oznakowane wydanie od mistrza, ale kiedy już wprowadzę poprawki, jak mogę ponownie pracować z wszelkimi poprawkami, które wprowadziłem w tym wydaniu. Wydaje się, że byłoby to raczej trudne.
Rocket04
Jeśli chcesz naprawić wiele wydań za pomocą tej samej poprawki, prawdopodobnie najpierw napraw najstarszą wersję i połącz ją z nowszą, dostosowując ją do każdej wersji. Jeśli pracujesz od nowego do starego, ryzykujesz usunięcie zależności z późniejszych wydań, co skomplikuje sytuację.
axl
I jak wspomniałem w mojej proponowanej odpowiedzi, gałąź master nie działa tak dobrze w przypadku wielu wydań na żywo, więc jeśli naprawdę nie potrzebujesz jej z jakiegoś powodu, radziłbym ci jej nie używać.
axl

Odpowiedzi:

9

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.

axl
źródło
3

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.

sentenza
źródło
1

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.

Gábor Angyal
źródło
Ale jak wspomniałem, w przypadku git-flow nie wydaje się, aby w ogóle używali gałęzi wydania. Nie brzmiało to tak, jakby działo się tam coś ważnego. Wydaje się również, że gałąź rozwoju jest w pewnym sensie bezużyteczna, jeśli pracujemy głównie w gałęziach wydania, równie dobrze możemy się go pozbyć, każda gałąź wydania jest zasadniczo gałąź rozwoju przez pewien okres czasu. A może coś mi brakuje?
Rocket04