Z razliko od centraliziranih sistemov za nadzor različic (CVCS-ji), vam narava porazdelitve Gita omogoča, da ste veliko bolj prilagodljivi v tem, kako razvijalci sodelujejo na projektih. V centraliziranih sistemih je vsak razvijalec vozlišče, ki deluje več ali manj enako z osrednjim razdelilnikom. Vendar v Gitu je vsak razvijalec potencialno tako vozlišče kot razdelilnik; to pomeni, da lahko vsak razvijalec tako prispeva kodo k drugim repozitorijem, kot tudi vzdržuje javen repozitorij, na katerem lahko drugi osnujejo svoje delo in h kateremu lahko prispevajo. To odpira širok spekter zmožnosti poteka dela za vaš projekt in/ali vašo ekipo, torej bomo pokrili nekaj pogostih paradigem, ki izkoriščajo to prilagodljivost. Šli bomo skozi prednosti in možne slabosti vsakega modela; za uporabo lahko izberete kateregakoli ali pa jih mešate in vzamete lastnosti iz vsakega.
V centraliziranih sistemih je v splošnem en model sodelovanja — centralizirani potek dela. En osrednji razdelilnik ali repozitorij lahko sprejme kodo in vsakdo sinhronizira svoje delo z njim. Število razvijalcev so vozlišča — uporabniki tega razdelilnika — in sinhronizirajo s to osrednjo lokacijo.
To pomeni, da če dva razvijalca klonirata iz razdelilnika in oba naredita spremembe, bo prvi razvijalec, ki potisne svoje spremembe nazaj gor, lahko to naredil brez težav. Drugi razvijalec mora združiti delo prvega, preden potisne spremembe gor, tako da ne prepiše sprememb prvega razvijalca. Ta zasnova je veljavna tako v Gitu kot tudi v Subversionu (ali kateremkoli drugem CVCS-ju) in ta model deluje v Gitu odlično.
Če ste že domači s centraliziranim potekom dela v svojem podjetju ali ekipi, lahko enostavno nadaljujete z uporabo tega poteka dela v Gitu. Enostavno nastavite repozitorij in daste vsakomur v svoji ekipi dostop potiskanja; Git ne bo dovolil uporabnikom prepisati drug drugega.
Recimo, da John in Jessica oba začneta delati istočasno. John konča svoje spremembe in jih potisne na strežnik. Nato poskuša Jessica potisniti svoje spremembe, vendar jih strežnik zavrne. Povedano ji je, da poskuša potisniti t. i. spremembe »brez hitrega previjanja naprej« (angl. non-fast-forward) in da tega ne bo mogla napraviti, dokler ne prenese in združi. Ta potek dela je zanimiv za veliko ljudi, ker je paradigma, s katero so mnogi seznanjeni in domači.
To tudi ni omejeno na majhne ekipe. Z modelom razvejanja Git je možno, da na stotine razvijalcev uspešno dela na istem projektu skozi ducat vej istočasno.
Ker vam Git omogoča imeti več oddaljenih repozitorijev, je možno imeti potek dela, kjer ima vsak razvijalec dostop za pisanje na svojem lastnem javnem repozitoriju in dostop za branje na vseh ostalih. Ta scenarij pogostokrat vključuje kanonični repozitorij, ki predstavlja »uradni« projekt. Da prispevate temu projektu, ustvarite svoj lastni javni klon projekta in vanj potisnete svoje spremembe. Nato lahko vzdrževalcu glavnega projekta pošljete zahtevek, da povleče vaše spremembe. Vzdrževalec lahko nato doda vaš repozitorij kot daljavo, testira vaše spremembe lokalno, jih združi v svojo vejo in potisne nazaj v svoj repozitorij. Proces deluje naslednje (glejte sliko Potek dela s povezovalnim upraviteljem):
-
Vzdrževalec projekta potisne v svoj javni repozitorij.
-
Sodelavec klonira ta repozitorij in naredi spremembe.
-
Sodelavec potisne v svojo lastno kopijo.
-
Sodelavec pošlje vzdrževalcu e-pošto, kjer ga prosi, da povleče spremembe.
-
Vzdrževalec doda repozitorij sodelavca kot daljavo in združi lokalno.
-
Vzdrževalec potisne združene spremembe v glavni repozitorij.
To je zelo pogost potek dela z orodji, ki so osnovana na razdelilnikih, kot sta GitHub ali GitLab, kjer je enostavno razvejiti (angl. fork) projekt in potisniti vaše spremembe v vašo razvejitev, da jih vsakdo vidi. Ena glavnih prednosti tega pristopa je, da lahko nadaljujete delo in vzdrževalec glavnega repozitorija lahko kadarkoli povleče vaše spremembe. Sodelavcem ni treba čakati, da projekt vključi njihove spremembe — vsaka stran lahko dela po svojem lastnem ritmu.
To je različica poteka dela z več repozitoriji. V splošnem je uporabljena 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 dobronamerni diktator. Dobronamerni diktator potisne iz svojega direktorija na referenčni repozitorij, iz katerega morajo vsi sodelavci povleči. Proces deluje takole (glejte sliko Potek dela z dobronamernim diktatorjem):
-
Splošni razvijalci delajo na svojih tematskih vejah in ponovno bazirajo svoje delo glede na
master. Vejamasterje veja referenčnega repozitorija, na katerega diktator potiska. -
Poročniki združijo razvijalčeve tematske veje v svojo vejo
master. -
Diktator združi poročnikove veje
masterv diktatorjevo vejomaster. -
Diktator potisne to vejo
masterv referenčni repozitorij, da lahko ostali razvijalci ponovno bazirajo na njem.
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č točkah, preden jih integrira.
|
Note
|
Martin Fowler je ustvaril vodnik »Patterns for Managing Source Code Branches«. Ta vodnik pokriva vse pogoste poteke dela Git in jih razloži, kako in kdaj jih uporabiti. Na voljo je tudi razdelek, ki primerja integracije visoke in nizke frekvence. |
To so nekateri pogosto uporabljeni poteki dela, ki so možni v porazdeljenih sistemih, kot je Git, vendar vidite lahko, da so možne mnoge različice, ki ustrezajo vašemu določenemu resničnemu 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 naslednjem razdelku se boste naučili o nekaterih pogostih vzorcih prispevanja projektu.