Git
Chapters ▾ 2nd Edition

5.1 Rozproszony Git - Rozproszone przepływy pracy

Teraz, gdy masz już skonfigurowane zdalne repozytorium, które służy do wymiany pracy między programistami w projekcie oraz jesteś zaznajomiony z podstawowymi komendami pozwalającymi na pracę z lokalnym repozytorium Git, zobaczysz jak wykorzystać jego możliwości w rozproszonym trybie pracy, który Git umożliwia.

W tym rozdziale, zobaczysz jak pracować z Gitem w rozproszonym środowisku jako współpracownik lub integrator zmian. Nauczysz się jak udostępniać wprowadzone zmiany oraz jak zrobić to najprościej jak tylko się da dla siebie i opiekuna projektu, oraz jak zarządzać projektem w którym uczestniczy wielu programistów.

Rozproszone przepływy pracy

Odmiennie do scentralizowanych systemów kontroli wersji (ang. Centralized Version Control Systems, CVCSs), rozproszona natura systemu Git pozwala na dużo bardziej elastyczne podejście do tego w jaki sposób przebiega współpraca między programistami. W scentralizowanych systemach każdy programista jest osobnym elementem pracującym na centralnym serwerze. W Gitcie każdy programista posiada zarówno swoje oddzielne repozytorium, które może zostać udostępnione dla innych, jak również centralny serwer do którego inni mogą wgrywać swoje zmiany. Umożliwia to szerokie możliwości współpracy dla Twojego projektu i/lub zespołu, dlatego opiszę kilka często używanych zachować które z tego korzystają. Pokażemy zalety i wady każdego z rozwiązań; możesz wybrać jeden odpowiadający tobie, lub możesz je połączyć i zmieszać ze sobą.

Scentralizowany przepływ 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

Scentralizowany przepływ pracy.
Figure 54. Scentralizowany przepływ pracy.

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.

Przepływ pracy z osobą integrującą zmiany

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.):

  1. Opiekun projektu wgrywa zmiany do publicznego repozytorium.

  2. Programiści klonują to repozytorium i wprowadzają zmiany.

  3. Programista wgrywa zmiany do swojego publicznego repozytorium.

  4. Programista wysyła prośbę do opiekuna projektu, aby pobrał zmiany z jego repozytorium.

  5. Opiekun dodaje repozytorium programisty jako repozytorium zdalne i pobiera zmiany.

  6. Opiekun wgrywa włączone zmiany do głównego repozytorium.

Przepływ pracy z osobą integrującą zmiany.
Figure 55. 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.

Przepływ pracy z dyktatorem i porucznikami

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.):

  1. Programiści pracują nad swoimi gałęziami tematycznymi, oraz wykonują rebase na gałęzi master. Gałąź master jest tą pobraną od dyktatora.

  2. Porucznicy włączają (merge) zmiany programistów do swojej gałęzi master.

  3. Dyktator włącza (merge) gałęzie master udostępnione przez poruczników do swojej gałęzi master.

  4. Dyktator wypycha (push) swoją gałąź master do głównego repozytorium, tak aby inni programiści mogli na niej pracować.

Przepływ pracy z miłościwym dyktatorem.
Figure 56. 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.

Podsumowanie przepływu pracy

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.

scroll-to-top