Przepływ pracy Git dla wielu zespołów

Zaczniemy używać Gita (jeszcze go nie używam) i chcę zdefiniować przepływ pracy.

Mamy 4 zespoły w 4 różnych globalnych lokalizacjach, które wspólnie opracowują ten sam produkt. Każdy zespół jest właścicielem części kodu produktu, ale czasami muszą również wprowadzić zmiany w kodzie należącym do innych zespołów.

Czy istnieje zalecenie dotyczące przepływu pracy Git dla takiego środowiska?

Widziałem już ten artykuł , ale podejście tutaj brzmi: „tworzymy dodatkowe gałęzie tak rzadko, jak to możliwe”, i wierzę bardziej w podejście „gałąź dla każdej historii użytkownika”.

Również ten artykuł przedstawia ładne podejście.

Miałem na myśli posiadanie gałęzi głównej, stałej gałęzi dla każdej drużyny okresowo łączącej się z mistrzem oraz gałęzi historii użytkownika łączących się z gałęziami zespołów. Czy to ma sens, czy nie zadziałałoby?

git version-control Igor Oks
źródło

Korzystamy z tego modelu rozgałęziania , ale myślę, że jeśli czytasz „gałąź funkcji” jako „gałąź historii”, to naprawdę dobrze komponuje się z twoim drugim artykułem.

Jestem pewien, że 10 osób może odpowiedzieć na to z 10 różnymi odpowiedziami. Oto, co działa dla mnie: Mamy jedno główne repozytorium hostowane na githubie, co oznacza „bieżącą” wersję. Starsze wersje są rozgałęzione (choć tagowanie również działa). Członkowie zespołu są zachęcani do tworzenia oddziałów dla zadań, nad którymi pracują. Po zakończeniu wysyłają żądanie ściągnięcia do master (lub gdziekolwiek musi się połączyć), a następnie ktoś inny przegląda żądanie pull i jest odpowiedzialny za scalenie go w master. Odpowiadają również za wyczyszczenie oddziału po jego połączeniu.

Możesz zainteresować się modułami podrzędnymi, aby rozdzielić bazy kodowe różnych zespołów. Następnie mogą wzajemnie rozwidlać bazy kodów i przesyłać łatki podczas edytowania wzajemnie części kodu.

Fred Foo,

@larsmans & carbonbasednerd - Twoje komentarze powinny być odpowiedziami, zyskałyby na mnie głosy. * 8 ')

Mark Booth,

Odpowiedzi:

Spójrz na udany model rozgałęziania Git , który ma przyjemną strategię rozgałęziania w zakresie rozwoju funkcji we wszystkich wydaniach.

Skuteczny model rozgałęziania git

Możesz zaimplementować coś podobnego z jednym dodatkowym poziomem dla gałęzi zespołu między gałęzią „rozwijaj” a „gałęziami funkcji”. Posiadanie oddziałów zespołu pozwoliłoby również dwóm zespołom na bardziej efektywną współpracę poprzez połączenie oddziałów zespołu.

Nick Haddad
źródło

Powiedziałbym, że każdy zespół ma swoją własną wersję repozytorium, z jednym globalnym repozytorium, do którego wszyscy się zobowiązują (jak w jądrze Linuksa, gdzie repozytorium Linus JEST jądrem i centralnym repozytorium).

Następnie, aby utrzymać kod produktu, możesz użyć podmodułów, takich jak @larsmans powiedział, wtedy każdy zespół może pracować głównie nad częścią, która jest dla nich najważniejsza, a jeśli muszą pracować z inną częścią, mogą to zrobić, ale będę musiał pamiętać o zaktualizowaniu submodułu, i na tym właśnie polega problem (ponieważ bardzo łatwo jest popełnić błąd podczas używania git, na szczęście łatwo jest od niego uciec).

Ale ponieważ twoje zespoły są do tego przyzwyczajone i zdają sobie sprawę, że zmieniają inny kod zespołu, łatwiej jest im pamiętać o aktualizacji podmodułu przed zmianą modułu obcego.

Coyote21
źródło