-
1. Pričetek
- 1.1 O nadzoru različic
- 1.2 Kratka zgodovina Gita
- 1.3 Kaj je Git?
- 1.4 Ukazna vrstica
- 1.5 Git namestitev
- 1.6 Prva namestitev 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 Git aliasi
- 2.8 Povzetek
-
3. Veje Git
- 3.1 Veje na kratko
- 3.2 Osnove vej in združevanja
- 3.3 Upravljanje vej
- 3.4 Potek dela z vejami
- 3.5 Oddaljene veje
- 3.6 Ponovno baziranje (rebasing)
- 3.7 Povzetek
-
4. Git na strežniku
- 4.1 Protokoli
- 4.2 Pridobiti Git na strežnik
- 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 Tretje osebne opcije gostovanja
- 4.10 Povzetek
-
5. Distribuirani Git
- 5.1 Razdeljeni poteki dela
- 5.2 Prispevanje projektu
- 5.3 Vzdrževanje projekta
- 5.4 Povzetek
-
6. GitHub
-
7. Orodja Git
- 7.1 Revision Selection
- 7.2 Interactive Staging
- 7.3 Stashing and Cleaning
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Rewriting History
- 7.7 Reset Demystified
- 7.8 Advanced Merging
- 7.9 Rerere
- 7.10 Debugging with Git
- 7.11 Submodules
- 7.12 Bundling
- 7.13 Replace
- 7.14 Credential Storage
- 7.15 Povzetek
-
8. Prilagoditev Gita
- 8.1 Git Configuration
- 8.2 Git Attributes
- 8.3 Kljuke Git
- 8.4 An Example Git-Enforced Policy
- 8.5 Povzetek
-
9. Git in ostali sistemi
- 9.1 Git kot klient
- 9.2 Migracija na Git
- 9.3 Povzetek
-
10. Notranjost Gita
- 10.1 Napeljava in keramika
- 10.2 Git Objects
- 10.3 Git References
- 10.4 Packfiles
- 10.5 Refspec
- 10.6 Transfer Protocols
- 10.7 Maintenance and Data Recovery
- 10.8 Environment Variables
- 10.9 Povzetek
-
A1. Dodatek A: Git v drugih okoljih
- A1.1 Grafični vmesniki
- A1.2 Git v programu 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 vododovodne sisteme
3.1 Veje Git - Veje na kratko
Skoraj vsak VCS ima neko obliko podpore vej. Veje pomenijo, da naredite raznolikost iz glavne linije razvoja in nadaljujete delo brez vpletanja v to glavno linijo. V mnogih orodjih VCS, je to nekoliko drag proces, ki od vas pogosto zahteva, da izdelate novo kopijo vašega direktorija izvorne kode, kar lahko vzame dalj časa za večje projekte.
Nekateri se sklicujejo na Gitov model razvejanja kot njegovo “ubijalsko lastnost” in zagotovo postavi Git stran od preostale VCS skupnosti. Zakaj je tako posebno? Način vej Git je izredno lahek, kar naredi operacije vej skoraj takojšnje ter preklaplanje nazaj in naprej med vejami je v splošnem tudi tako hitro. Z razliko od ostalih VCS-jev, Git spodbuja potek dela, ki pogosto ustvari veje in jih združi, celo večkrat na dan. Razumevanje in osvojitev te lastnosti vam da močno in unikatno orodje in lahko v celoti spremeni način, kako razvijate.
Veje na kratko
Za resnično razumevanje, na kakšen način Git dela razvejanje, se moramo vrniti korak nazaj in raziskati, kako Git shranjuje svoje podatke.
Kakor se morda spomnite iz [ch01-introduction], Git ne shranjuje podatkov kot serije skupkov sprememb ali razlik, vendar namesto tega kot serije posnetkov.
Ko naredite pošiljanje, Git shrani objekt pošiljanja, ki vsebuje kazalec k posnetku vsebine, ki ste jo dali v vmesno fazo. Ta objekt tudi vsebuje ime avtorja in e-pošto, sporočilo, ki ste jo vpisali in kazalce k pošiljanju ali pa pošlje to, kar je direktno prišlo pred tem pošiljanjem (svoj starš od staršev): nobenih staršev za začetne pošiljanje, en starš za običajno pošiljanje in več staršev za pošiljanje, ki je rezultat združevanja dveh ali več vej.
Da to vizualiziramo, predpostavimo, da imate direktorij, ki vsebuje tri datoteke in vse date v vmesno fazo in pošljete. Dajanje datotek v vmesno fazo preveri vsote vsake (SHA-1 zgoščevanje, ki smo ga omenili v [ch01-introduction]) shrani to verzijo datoteke v Git repozitorij (Git se sklicuje nanj kot blob) in doda to preverjeno vsoto v vmesno fazo:
$ git add README test.rb LICENSE
$ git commit -m 'initial commit of my project'
Ko ustvarite pošiljanje z pogonom git commit
, Git preveri vsote za vsak poddirektorij (v tem primeru samo vrhnji direktorij projekta) in shrani te objekte drevesa v Git repozitorij.
Git nato ustvari objekt pošiljanja, ki ima meta podatke in kazalec na vrhnje drevo projekta, da lahko ponovno ustvari posnetek, ko je potrebno.
Vaš repozitorij Git sedaj vsebuje pet objektov: en blob za vsebine vsake od vaših treh datotek, eno drevo, ki izpisuje seznam vsebine direktorija in določa katera imena datotek so shranjena kot blob-i in eno pošiljanje s kazalcem na vrhnje drevo in vse meta podatke pošiljanja.

Če naredite nekaj sprememb in nato ponovno pošljete, naslednje pošiljanje shrani kazalec k pošiljanju, ki je prišlo takoj pred tem.

Veja v Git-u je enostavno lahek prenosen kazalec k enemu od teh pošiljanj.
Privzeto ime veje v Git-u je master
.
Kot ste začeli delati pošiljanja, imate dano master vejo, ki kaže na zadnje pošiljanje, ki ste ga naredili.
Vsakič, ko pošljete, ga premakne naprej avtomatsko.
Opomba
|
Veja |

Ustvarjanje nove veje
Kaj se zgodi, če ustvarite novo vejo?
No, to naredi nov kazalec za vas, da se premika okoli.
Recimo, da ustvarite novo vejo imenovano testing.
To naredite z ukazom git branch
:
$ git branch testing
To ustvari nov kazalec na isto pošiljanje, na katerem ste trenutno.

Kako Git ve, na kateri veji ste trenutno?
Ima poseben kazalec imenovan HEAD
.
Bodite pozorni, da je to precej različno od koncepta HEAD
v drugih VCS-jih, ki ste ga morda vajeni, kot sta Subversion ali CVS.
V Git-u je to kazalec na lokalno vejo, kjer ste trenutno.
V tem primeru ste še vedno na master.
Ukaz git branch
je samo ustvaril novo vejo - ni preklopil na to vejo.

To lahko enostavno pogledate, da poženete ukaz git log
, ki vam prikaže, kam kazalec veje kaže. Ta opcija se imenuje --decorate
.
$ git log --oneline --decorate
f30ab (HEAD, master, testing) add feature #32 - ability to add new
34ac2 fixed bug #1328 - stack overflow under certain conditions
98ca9 initial commit of my project
Vidite lahko master'' in
testing'' veji, ki sta ravno tam zraven pošiljanja f30ab
.
Switching Branches
Da preklopite obstoječo vejo, poženete ukaz git checkout
.
Preklopimo na novo testing vejo:
$ git checkout testing
To prestavi HEAD
, da kaže na vejo testing
.

Kaj je pomembnost tega? Torej naredimo drugo pošiljanje:
$ vim test.rb
$ git commit -a -m 'made a change'

To je zanimivo, ker je sedaj vaša testing veja premaknjena naprej, vendar vaša master veja še vedno kaže na pošijanje, kjer ste bili, ko ste pognali git checkout
, da ste preklopili veje.
Preklopimo nazaj na master vejo:
$ git checkout master

Ta ukaz naredi dve stvari. Premaknil je HEAD kazalec nazaj na točko master veje in povrnil datoteke v vašem delovnem direktoriju nazaj na posnetek, kamor master kaže. To tudi pomeni, da se bodo spremembe, ki jih delate od te točke naprej, razlikovale od starejše verzije projekta. Pomembno je presneti nazaj delo, ki ste ga naredili na vaši testing veji, ta lahko greste v različno smer.
Opomba
|
Switching branches changes files in your working directory
Pomembno je opozoriti, da ko preklopite veje v Git-u, se datoteke v vašem delovnem direktoriju spremenijo. Če ste preklopili na starejšo vejo, bo vaš delovni direktorij prestavljen nazaj, da bo izgledal tako kot je prejšnjič, ko ste poslali na tisti veji. Če Git to ne more narediti čisto, vam ne bo dovolil preklopiti. |
Naredimo nekaj sprememb in ponovno pošljimo:
$ vim test.rb
$ git commit -a -m 'made other changes'
Sedaj se je vaša zgodovina projekta spremenila (glejte Divergent history).
Ustvarili in preklopili ste vejo, naredili nekaj dela na njej in nato preklopili nazaj na vašo glavno vejo in naredili drugo delo.
Obe od teh sprememb so izolirane v ločenih vejah: lahko preklopite nazaj in naprej med vejama in ju združite skupaj, ko ste pripravljeni.
In naredili ste vse to z enostavnimi ukazi branch
, checkout
in commit
.

Lahko tudi vidite to enostavno z ukazom git log
.
Če poženete git log --oneline --decorate --graph --all
bo izpisal zgodovino vaših pošiljanj, prikazal, kje so kazalci vej in kako se je vaša zgodovina spremenila.
$ git log --oneline --decorate --graph --all
* c2b9e (HEAD, master) made other changes
| * 87ab2 (testing) made a change
|/
* f30ab add feature #32 - ability to add new formats to the
* 34ac2 fixed bug #1328 - stack overflow under certain conditions
* 98ca9 initial commit of my project
Ker je veja v Git-u dejansko enostavna datoteka, ki vsebuje 40 znakovno SHA-1 preverjeno vsoto pošiljanja, kamor kaže, so veje poceni za izdelati in uničiti. Ustvarjanje nove veje je hitro in enostavno kakor napisati 41 bajtov v datoteko (40 znakov in nova vrstica).
To je v ostrem kontrastu z načinom večine vej starejših VCS orodij, ki vključujejo kopiranje vseh datotek projekta v drug direktorij. To lahko vzame nekaj sekund ali celo minut, odvisno od velikosti projekta, kjer je v Git-u proces vedno takojšnji. Tudi ker snemate starše, ko pošljete, iščete ustrezno združevalno osnovo, saj je združevanje narejeno avtomatično za nas in je v splošnem zelo enostavno narediti. Te lastnosti pomagajo spodbujati razvijalcem ustvariti in uporabiti veje pogostokrat.
Poglejmo zakaj bi to morali tako narediti.