Git
Chapters ▾ 2nd Edition

5.1 Distribuirani Git - Distribuirani poteki dela

Sedaj, ko imate oddaljeni repozitorij Git nastavljen kot točko za vse razvijalce, da delijo svojo koto in so vam poznani osnovni ukazi Git v lokalnem poteku dela, boste pogledali, kako uporabiti nekaj distribuiranih potekov dela, ki vam jih ponuja Git.

V tem poglavju, boste videli, kako delati z Git-om v distribuiranem okolju kot sodelavec in povezovalec. To pomeni, da se boste naučili, kako prispevati projektu kodo uspešno in narediti kakor enostavno za vas in vzdrževalca projekta je možno in tudi kako uspešno vzdrževati projekt s številnimi razvijalci, ki prispevajo.

Distribuirani poteki dela

Z razliko od centraliziranih sistemov za kontrolo verzija (CVCS-ji), vam narava distribucije Git-a omogoča, da ste veliko bolj fleksibilni v tem, kako razvijalci sodelujejo na projektih. V centraliziranih sistemih je vsak razvijalec vozlišče, ki bolj ali manj dela enako na centralnem središče. Vendar v Git-u vsak razvijalec je potencialno oboje vozlišče in središče - to je, vsak razvijalec lahko tako prispeva kodo k drugim repozitorijem in vzdržuje javen repozitorij na katerem ostali lahko osnujejo svoje delo in h katerem lahko prispevajo. To odpira širok spekter zmožnosti poteka dela za vaš projekt in/ali vašo ekipo, torej bomo pokrili nekaj pogostih paradigm, ki izkoriščajo to fleksibilnost. Šli bomo skozi prednosti in možne slabosti vsakega modela; lahko izberete kateregakoli za uporabo ali mešate in ujamete lastnosti iz vsakega.

Centraliziran potek 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.

Centralized workflow.
Figure 54. Centralized workflow.

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.

Potek dela povezovalnega upravitelja

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

  1. Vzdrževalec projekta porine v svoj javni repozitorij.

  2. Prispevalec klonira ta repozitorij in naredi spremembe.

  3. Prispevalec porine v svojo lastno kopijo.

  4. Prispevalec pošlje vzdrževalcu e-pošto, kjer ga prosi, da potegne spremembe.

  5. Vzdrževalec doda repozitorij prispevalca kot daljavo in združi lokalno.

  6. Vzdrževalec porine zdrzžene spremembe v glavni repozitorij.

Integration-manager workflow.
Figure 55. 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.

Potek dela diktator in poročniki

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

  1. Splošni razvijalci delajo na njihovih tematskih vejah in ponovno bazirajo svoje delo na glede na master. Veja master je veja diktatorja.

  2. Poročniki združijo razvijalčeve tematske veje v svojo vejo master.

  3. Diktator združi poročnikove veje master v diktatorjevo vejo master.

  4. Diktator porine svojo master v referenčni repozitorij, da ostali razvijalci lahko ponovno bazirajo na njem.

Benevolent dictator workflow.
Figure 56. 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

Povzetek poteka dela

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.