5.1 Rozproszony Git - Rozproszone przepływy pracy

W scentralizowanych systemach, zazwyczaj jest stosowany model centralnego przepływu. W jednym centralnym punkcie znajduje się repozytorium, do którego wgrywane są zmiany, a pozostali współpracownicy synchronizują swoją pracę z nim. Wszyscy programiści uczestniczący w projekcie są końcówkami, łączącymi się z centralnym serwerem – oraz synchronizującymi się z nim

Oznacza to tyle, że w sytuacji w której dwóch niezależnych programistów korzystających z tego centralnego repozytorium będzie próbowało wgrać swoje zmiany, tylko pierwszemu z nich uda się tego dokonać bezproblemowo. Drugi przed wgraniem, będzie musiał najpierw pobrać i zintegrować zmiany wprowadzone przez pierwszego programistę, a dopiero później ponowić próbę wysłania swoich na serwer. Taki rodzaj współpracy sprawdza się doskonale w Gitcie, tak samo jak funkcjonuje on w Subversion (lub każdym innym CVCS).

Jeżeli masz mały zespół, lub dobrze znacie pracę z jednym centralnym repozytorium w firmie lub zespole, możesz bez problemów kontynuować ten rodzaj pracy z Gitem. Po prostu załóż nowe repozytorium, nadaj każdej osobie z zespołu uprawnienia do wgrywania zmian (za pomocą komendy push); Git nie pozwoli na nadpisanie pracy jednego programisty przez innego. Powiedzmy, że John i Jessica zaczynają pracować w tym samym czasie. John kończy wprowadzać swoje zmiany i przesyła je na serwer. Następnie Jessica próbuje wysłać swoje zmiany, ale serwer je odrzuca. Dostaje informację zwrotną, że próbuje wysłać zmiany nie będące w trybie przewijania do przodu (not-fast-forward), i że nie będzie mogła tego zrobić, dopóki nie pobierze (fetch) i nie połączy (merge) zmian.

Nie jest to również ograniczone do małych zespołów. Dzięki modelowi rozgałęziania Gita, możliwe jest, aby setki programistów z powodzeniem pracowało jednocześnie nad jednym projektem poprzez dziesiątki gałęzi.

Ponieważ Git powala na posiadanie wielu zdalnych repozytoriów, możliwy jest schemat pracy w którym każdy programista ma uprawnienia do zapisu do swojego własnego repozytorium oraz uprawnienia do odczytu do repozytorium innych osób w zespole. Ten scenariusz często zawiera jedno centralne "oficjalne" repozytorium projektu. Aby wgrać zmiany do projektu, należy stworzyć publiczną kopię tego repozytorium i wgrać (push) zmiany do niego. Następnie należy wysłać prośbę do opiekuna aby pobrał zmiany do głównego repozytorium. Może on dodać Twoje repozytorium jako zdalne, przetestować Twoje zmiany lokalnie, włączyć je do nowej gałęzi i następnie wgrać do repozytorium. Proces ten wygląda następująco (por. Przepływ pracy z osobą integrującą zmiany.):

To jest bardzo popularne podejście podczas współpracy przy pomocy stron takich jak GitHub lub GitLab, gdzie bardzo łatwo można stworzyć kopię repozytorium i wgrywać zmiany do niego aby każdy mógł je zobaczyć. Jedną z głównych zalet takiego podejścia jest to, że możesz kontynuować pracę, a opiekun może pobrać Twoje zmiany w dowolnym czasie. Programiści nie muszą czekać na opiekuna, aż ten włączy ich zmiany – każdy z nich może pracować oddzielnie.

To jest wariant przepływu z wieloma repozytoriami. Zazwyczaj jest on używany w bardzo dużych projektach, z setkami programistów; najbardziej znanym przykładem może być jądro Linuksa. Kilkoro opiekunów jest wydelegowanych do obsługi wydzielonych części repozytorium; nazwijmy ich porucznikami. Wszyscy z nich mają jedną, główną osobę integrującą zmiany – znaną jako miłościwy dyktator. Repozytorium dyktatora jest wzorcowym, z którego wszyscy programiści pobierają zmiany. Cały proces działa następująco (por. Przepływ pracy z miłościwym dyktatorem.):

Ten rodzaj współpracy nie jest częsty w użyciu, ale może być użyteczny w bardzo dużych projektach, lub bardzo rozbudowanych strukturach zespołów. Pozwala liderowi projektu (dyktatorowi) na delegowanie dużej części pracy i zbieranie dużych części kodu w wielu punktach czasu przed ich zintegrowaniem.

To są najczęściej stosowane przepływy pracy możliwe przy użyciu rozproszonego systemu takiego jak Git, jednak możesz zauważyć że istnieje w tym względzie duża dowolność, tak abyś mógł dostosować go do używanego przez siebie tryby pracy. Teraz gdy (miejmy nadzieję) możesz już wybrać sposób pracy który jest dla Ciebie odpowiedni, pokażemy kilka konkretnych przykładów w jaki sposób osiągnąć odpowiedni podział ról dla każdego z opisanych przepływów. W następnej części dowiesz się o kilku popularnych wzorcach współtworzenia projektu.