5.1 Distribuirani Git - Razdeljeni poteki dela

V centraliziranih sistemih je v splošnem en modelo sodelovanja - centralizirani potek dela. Centralno središče ali repozitorij lahko sprejema kodo in vsakdor sinhronizira svoje delo nanj. Število razvijalcev so vozlišča - uporabniki tega središča - in sinhronizirajo na to lokacijo.

To pomeni, da če dva razvijalca klonirata iz središča in oba naredita spremembe, prvi razvijalec, ki porine svoje spremembe nazaj gor, lahko to naredi brez problemov. Drugi razvijalec mora združiti delo prvega preden poriva spremembe gor, da ne prepiše sprememb prvega razvijalca. Ta koncept je tako resničen v Git-u kot tudi v Subversion-u (ali kateremkoli drugem CVCS-ju) in ta model deluje odlično v Git-u.

Če ste že udobni s centraliziranim potekom dela v vašem podjetju ali ekipi, lahko enostavno nadaljujete z uporabo tega poteka dela v Git-u. Enostavno nastavite en repozitorij in dajte vsakomur v vaši ekipi dostop porivanja; Git ne bo dovolil uporabnikov prepisati drug drugega. Recimo, da John in Jessica oba začneta delati istočasno. John konča svoje spremembe in jih porine na strežnik. Nato Jessica poskuša poriniti njene spremembe, vendar jih strežnik zavrne. Povedano ji je, da poskuša poriniti t.i. non-fast-forward spremembe in da tega ne bo mogla narediti dokler ne ujame in združi. Ta potek dela je atraktiven za veliko ljudi, ker je paradigma, s katero so mnogi seznanjeni in udobni.

To tudi ni omejeno na majhne ekipe. Z Git modelom razvejanja, je možno za stotine razvijalcev, da uspešno delajo na enem projektu skozi ducat vej simultano.

Ker vam Git omogoča imeti več oddaljenih repozitorijev, je možno imeti potek dela, kjer ima vsak razvijalec pisalni dostop do svojega lastnega javnega repozitorija in bralni dostop do vseh ostalih. Ta scenarij pogosto vključuje kanonični repozitorij, ki predstavlja ``uradni'' projekt. Da prispevate temu projektu, ustvarite vaš lastni javni klon projekta in porinete vaše spremembe vanj. Nato lahko pošljete zahtevek vzdrževalcu glavnega projekta, da potegne vaše spremembe. Vzdrževalec lahko nato doda vaš repozitorij kot daljavo, testira vaše spremembe lokalno, jih združi v svojo vejo in porine nazaj v svoj repozitorij. Proces deluje sledeče (glejte Integration-manager workflow.):

To je zelo pogost potek dela z orodji s središčno-osnovo kot sta GitHub ali GitLab, kjer je enostavno "forkati" projekt in poriniti vaše spremembe v vaš fork, da jih vsakdo vidi. Ena glavnih prednosti tega pristopa je, da lahko nadaljujete delo in vzdrževalec glavnega repozitorija lahko potegne vaše spremembe kadarkoli. Prispevalcem ni treba čakati, da projekt vključi njihove spremembe - vsaka stran lahko dela po svojem lastnem ritmu.

To je različica poteka dela večih repozitorijev. V splošnem je uporabljen na velikih projektih s stotinami sodelavcev; eden znanih primerov je jedro Linux Različni upravitelji integracij so zadolženi za določene dele repozitorija; imenujejo se poročniki. Vsi poročniki imajo enega upravitelja integracije znanega kot dobrohotni diktator. Repozitorij dobrohotnega diktatorja služi kot referenčni repozitorij iz katerega morajo vsi sodelavci potegniti. Proces deluje takole (glejte Benevolent dictator workflow.):

Taka vrsta poteka dela ni pogosta, vendar je lahko uporabna v zelo velikih projektih ali v visoko hierarhičnih okoljih. Vodji projekta (diktatorju) omogoča delegirati večino dela in zbrati velike skupke kode na večih točkah preden jih integrira

To so nekatere pogosto uporabljeni poteki dela, ki so možni v distribuiranih sistemih kot je Git, vendar lahko vidite, da so možne mnoge različice, ki ustrezajo vašem določenem realnem poteku dela. Sedaj ko lahko (upajmo) določite katera kombinacija poteka dela lahko deluje za vas, bomo pokrili nekaj določenih primerov kako doseči glavne vloge, ki naredijo različne poteke. V naslednji sekciji, se boste naučili o nekaterih pogostih vzorcih prispevanja projektu.