Gitflow z wieloma gałęziami wzorcowymi

Question

Chociaż jest to podobne do wątku Git-flow and master with multiple parallel release-branches i What's best way to work with git on multiple master branch?, to nie jest całkiem identyczne ... Stwierdziłem, że ten jest podobny: Multiple projects with same GIT master, ale chcę omówić mój konkretny przypadek użycia ...

Firma, w której pracuję, jest w trakcie opracowywania zasad i procedur dla naszego przepływu pracy Git. Chcemy użyć modelu "Gitflow", jak opisano w artykule http://nvie.com/posts/a-successful-git-branching-model/ lub https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow i jest on powszechnie stosowany w wielu dyskusjach na ten temat.

Mamy jednak przypadek użycia z wymaganiem, dla którego nie mogę znaleźć rozwiązania udokumentowanego. Co się stanie, jeśli twój projekt zostanie wykorzystany do wytworzenia więcej niż jednego produktu końcowego? Oddział główny nie może zatem reprezentować "punktów uwolnienia", jak gdyby był to pojedynczy produkt. Wygląda na to, że od kapitana potrzebne mogą być kolejne gałęzie? A więc wiele oddziałów o równoległym uwalnianiu?

Na przykład, jeśli projekt działa jako szkielet lub silnik do czegoś, co może mieć różne skórki, smaki lub odmiany, ale chcesz, aby każdy z końcowych produktów końcowych przechowywany był w jednym repozytorium?

W moim szczególnym scenariuszu, mam program, który działa na serwerze Linux, ale jest również dystrybuowany jako lokalna aplikacja Windows. W tych różnych wersjach istnieją duże fragmenty projektu, które mogą lub nie mogą być zawarte w jednym lub w innych wydaniach. Przykładowo na serwerze znajdują się biblioteki, których nie trzeba uwzględniać, jeśli repo dotyczyło tylko serwera, ale które należy uwzględnić w lokalnej dystrybucji, gdzie w przeciwnym razie nie istniałyby. Chcę pobrać aktualizację repo na serwer w określonych punktach wydania, ale pomiń takie części, które do niego nie należą.

Czy z gałęzi głównej utworzę gałąź "Wydanie serwera" i "Lokalne wydanie"?

Skąd się wzięła gałąź rozwojowa (i jej funkcje)? Nie chcę wielu gałęzi rozwojowych, z których każda pochodzi z własnej wersji, ponieważ rozwój kodu w rzeczywistości dotyczy 99% tych dwóch. Czy muszę scalić pojedynczą gałąź dev w jedną, a następnie drugą wersję?

Answer 1

Jeśli 99% kodu jest dzielone między tymi dwoma produktami, można łatwo udostępnić to samo repozytorium. Możesz mieć jedną gałąź release/develop/master, o ile oba produkty są w tym samym cyklu wydawania, np. W tym samym czasie dostarczana jest wersja 2.0.

Czy z gałęzi głównej utworzę gałąź "Wydanie serwera" i "Lokalne wydanie"?

W gitflow faktycznie wydawane są gałęzie od dewelopera! Ale w przypadku, gdy są w różnych cyklach wydań, nic nie powstrzyma cię od stworzenia gałęzi wydania na produkt. Wtedy możesz łączyć gałęzie uwolnienia z gałęziami rozwijającymi się i nadrzędnymi, gdy są one wykonywane we własnym czasie. Jedyną rzeczą jest to, że prawdopodobnie będziesz potrzebował dwóch różnych smaków tagów w gałęzi głównej, abyś mógł zobaczyć, gdzie każdy z produktów znajduje się w cyklu wydawniczym. Jeśli chcesz zachować tagi w tym samym formacie, możesz mieć dwie główne gałęzie (po jednej dla każdego produktu), które scalą się odpowiednio, gdy funkcja zostanie ukończona dla danego produktu.