Jestem liderem zespołu w naszej firmie zajmującej się tworzeniem stron internetowych i chciałbym wdrożyć przepływ pracy Git w naszym zespole. Czytając dokumentację i artykuły znalazłem dla nas następującą strukturę:

Mamy repozytorium w Bitbucket.Mistrz gałąź jest uważana za zawierającą tylko stabilny kod. Każdy dev musi stworzyć własną gałąź i zaimplementować funkcje / poprawki błędów w swoimposiadać Oddział. Gdy zdecyduje, że jego kod jest gotowy, tworzy ładną historię oddziału (używając rebase, change, cherry-pick itp.) I przesyła go do Bitbucket, gdzie tworzy żądanie ściągnięcia do gałęzi master. QA weryfikuje funkcjonalność i zatwierdza ją (lub odrzuca), następnie weryfikuję kod i jeśli jest w porządku, łączę jego pracę w master (przez szybkie przewijanie do przodu lub rebasing dla lepszej historii zatwierdzeń).

Ale ten schemat jest dobry tylko w przypadku, gdy pojedynczy programista pracuje na oddziale. W naszym przypadku prawie zawsze mamy dwóch programistów dla jednego oddziału, ponieważ pracuje nad nim jeden programistapo stronie serwera (PHP) i inne -Strona klienta (HTML / CSS / JS). W jaki sposób ci dwaj powinni współpracować w taki sposób, że historia popełniania błędów u mistrza pozostaje czysta?

Serwer dev tworzy podstawową strukturę plików HTML, a dev dev musi uzyskać tę strukturę. Logicznie byłoby, gdyby serwer dev utworzył oddział, a klient dev utworzył własny oddział oparty na gałęzi serwera dev. Ale to oznacza, że ​​serwer musipublikować jego oddział w Bitbucket, który to zrobiniemożliwe dla niego ponowne podstawienie lub zmiana zatwierdzeń, które są już opublikowane.

Inną opcją jest czekanie, aż serwer dev zakończy pracę, opublikuje gałąź z ładną historią zatwierdzeń i zapomni o tym, a dopiero po tym, jak dev client zacznie działać w tej branży, ale spowoduje to opóźnienia, co jest jeszcze gorsze.

Jak radzisz sobie z taką współpracą w swoich przepływach pracy?