-
1. Začetek
- 1.1 O nadzoru različic
- 1.2 Kratka zgodovina Gita
- 1.3 Kaj je Git?
- 1.4 Ukazna vrstica
- 1.5 Namestitev Gita
- 1.6 Prva nastavitev Gita
- 1.7 Pridobivanje pomoči
- 1.8 Povzetek
-
2. Osnove Git
- 2.1 Pridobivanje repozitorija Git
- 2.2 Snemanje sprememb v repozitorij
- 2.3 Pregled zgodovine potrditev
- 2.4 Razveljavljanje stvari
- 2.5 Delo z daljavami
- 2.6 Označevanje
- 2.7 Aliasi Git
- 2.8 Povzetek
-
3. Veje Git
- 3.1 Veje na kratko
- 3.2 Osnove vej in združevanja
- 3.3 Upravljanje vej
- 3.4 Poteki dela z vejami
- 3.5 Oddaljene veje
- 3.6 Ponovno baziranje
- 3.7 Povzetek
-
4. Git na strežniku
- 4.1 Protokoli
- 4.2 Pridobitev Gita na strežniku
- 4.3 Generiranje vaših javnih ključev SSH
- 4.4 Nastavitev strežnika
- 4.5 Prikriti proces Git
- 4.6 Pametni HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Možnosti gostovanja pri tretjih ponudnikih
- 4.10 Povzetek
-
5. Porazdeljeni Git
- 5.1 Porazdeljeni poteki dela
- 5.2 Prispevek k projektu
- 5.3 Vzdrževanje projekta
- 5.4 Povzetek
-
6. GitHub
-
7. Orodja Git
- 7.1 Izbira revizije
- 7.2 Interaktivno pripravljanje
- 7.3 Shranjevanje na varno (angl. stashing) in čiščenje
- 7.4 Podpisovanje vašega dela
- 7.5 Iskanje
- 7.6 Prepisovanje zgodovine
- 7.7 Demistifikacija ponastavitve
- 7.8 Napredno združevanje
- 7.9 Rerere
- 7.10 Razhroščevanje z Gitom
- 7.11 Podmoduli
- 7.12 Povezovanje v pakete
- 7.13 Zamenjava
- 7.14 Shramba poverilnic
- 7.15 Povzetek
-
8. Prilagoditev Gita
- 8.1 Konfiguracija Git
- 8.2 Atributi Git
- 8.3 Kljuke Git
- 8.4 Primer pravilnika, ki ga uveljavlja Git
- 8.5 Povzetek
-
9. Git in ostali sistemi
- 9.1 Git kot odjemalec
- 9.2 Migracija na Git
- 9.3 Povzetek
-
10. Notranjost Gita
- 10.1 Napeljava in keramika
- 10.2 Objekti Git
- 10.3 Reference Git
- 10.4 Packfiles (datoteke zmanjšanih podatkov)
- 10.5 Refspec
- 10.6 Protokoli prenosa
- 10.7 Vzdrževanje in obnovitev podatkov
- 10.8 Spremenljivke okolja
- 10.9 Povzetek
-
A1. Dodatek A: Git v drugih okoljih
- A1.1 Grafični vmesniki
- A1.2 Git v Visual Studio
- A1.3 Git v Visual Studio Code
- A1.4 Git v IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git v Sublime Text
- A1.6 Git v Bashu
- A1.7 Git v Zsh
- A1.8 Git v Powershellu
- A1.9 Povzetek
-
A2. Dodatek B: Vdelava Gita v vašo aplikacijo
- A2.1 Git v ukazni vrstici
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Dodatek C: Ukazi Git
- A3.1 Nastavitev in konfiguracija
- A3.2 Pridobivanje in ustvarjanje projektov
- A3.3 Osnove posnetkov
- A3.4 Veje in združevanje
- A3.5 Deljenje in posodabljanje projektov
- A3.6 Pregled in primerjava
- A3.7 Razhroščevanje
- A3.8 Popravljanje
- A3.9 E-pošta
- A3.10 Zunanji sistemi
- A3.11 Administracija
- A3.12 Orodja za sisteme napeljave
5.1 Porazdeljeni Git - Porazdeljeni poteki dela
Sedaj, ko imate oddaljeni repozitorij Git nastavljen kot točko za vse razvijalce, da delijo svojo kodo, in so vam poznani osnovni ukazi Git v lokalnem poteku dela, boste pogledali, kako uporabiti nekaj porazdeljenih potekov dela, ki vam jih ponuja Git.
V tem poglavju boste spoznali, kako delati z Gitom v porazdeljenem okolju kot sodelavec in povezovalec. To pomeni, da se boste naučili, kako uspešno prispevati kodo projektu in to narediti, kar se da enostavno za vas in vzdrževalca projekta, ter kako uspešno vzdrževati projekt s številnimi razvijalci, ki prispevajo.
Porazdeljeni poteki dela
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.
Centraliziran potek dela
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.
Potek dela s povezovalnim upraviteljem
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.
Potek dela z diktatorji in poročniki
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
. Vejamaster
je 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
master
v diktatorjevo vejomaster
. -
Diktator potisne to vejo
master
v 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.
Vzorci za upravljanje vej izvorne kode
Opomba
|
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. |
Povzetek potekov dela
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.