Nasza linia oprogramowania wymaga jednoczesnego opracowywania i utrzymywania wielu wersji oprogramowania. Jesteśmy względnymi nowicjuszami Git i niedawno przyjęliśmy Git Flow, aby skorzystaćModel rozgałęzienia Driessena. Mamy bardzo mały zespół programowy z kilkoma dedykowanymi programistami (wszyscy nosimy wiele czapek) i nie ma żadnego „guru integracji”.

Wiele poszukiwań okazało się mało konkretną radą, jak dostosować Git i Git Flow do naszych potrzeb. Okazało się, że Git Flow nie jest odpowiedni do jednoczesnego obsługiwania wielu wersji. Jedenzwiązana z tym dyskusja na temat SO ma odpowiedzi wskazujące, że należy użyć oddzielnych nazw oddziałów, aby śledzić historie poszczególnych wersji. To i powiązane strategie eliminują Git Flow, chyba że zostanie zmodyfikowany; zobacz nasze ograniczenia zespołu powyżej z tego powodu, dla którego nie jest to dla nas praktyczne.

Kluczowe pytanie brzmi: co inni uznali za dobre podejście do wdrożenia modelu rozgałęzienia Driessena tak blisko, jak to możliwe, przy jednoczesnym wspieraniu wielu linii wydawniczych?

AKTUALIZACJE:

Poniższe odpowiedzi (szczególnie @Rasmus) z bardziej ukierunkowanymi wyszukiwaniami i wewnętrznymi dyskusjami na temat kilku opcji prowadzą do następującego rozwiązania, które wdrażamy i które oferuję jako jedno podejście, które może być odpowiednie dla podobnych zespołów w podobnych warunkach.

Nie będziemy nadal używać Git Flow. Zamiast tego zastosujemy model Driessena do każdej indywidualnej linii wydania w repozytorium, poprzedzając nazwę każdej gałęzi jej zamierzonym ciągiem uwolnienia, np .:

r1.5/develop

Wszystkie wersje projektu znajdują się w repozytorium Git. Rozpoczęcie nowej wersji projektu polega na utworzeniu małego zestawu nowych długowiecznych gałęzi poprzedzonych ciągiem uwalniania (np.r1.6/develop iw naszym przypadkur1.6/release; Niemaster z implikacją pojedynczego aktualnego dobrego stanu do zbudowania).

Ustanawiamy jedno centralne publiczne repozytorium na projekt na serwerze, który będzie główną drogą udostępniania kodu za pośrednictwem lokalnego reporemote spinki do mankietów. Push do tego repozytorium oznacza kod, który jest gotowy do wykorzystania przez innych. ŁączenieRX.Y/develop w, a następnie naciskającRX.Y/release gałąź oznacza kod przeznaczony do wydania.feature, hotfix, et. glin. oddziały są traktowane podobnie. Historia scalania / zatwierdzania gałęzi dla danej linii wydania jest czysta i zrozumiała. Nie chcemy, aby typowa strategia repozytorium Git polegała na unikaniu złożoności łączenia takich transakcji, które z czasem mogą się różnić w strukturze.

W niektórych GUI Git (takich jak na przykład SourceTree) ta struktura gałęzi jest rozpoznawana i wyświetlana jako hierarchiczna, co pomaga zrozumieć historię najwyższego poziomu projektu ze struktury gałęzi.

Przepraszam za brak głosowania na żadne odpowiedzi; moja reputacja na SO nie jest jeszcze minimum wymaganym do tego.