-
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
3.1 Veje Git - Veje na kratko
Skoraj vsak VCS ima neko obliko podpore razvejanja. Razvejanje pomeni, da se odmaknete od glavne razvojne linije in nadaljujete delo brez vpletanja v to glavno linijo. V mnogih orodjih VCS je to nekoliko drag postopek, ki od vas pogosto zahteva, da izdelate novo kopijo svojega direktorija izvorne kode, kar lahko traja dolgo časa za večje projekte.
Nekateri se sklicujejo na Gitov model razvejanja kot na njegovo »najboljšo značilnost« in zagotovo postavi Git stran od preostale skupnosti VCS. Zakaj je tako poseben? Način razvejanja v Gitu je izredno lahek, kar omogoča skoraj trenutne operacije razvejanja in hitro preklapljanje med vejami naprej in nazaj. V primerjavi z mnogimi ostalimi VCS-ji, Git spodbuja poteke dela, ki pogosto ustvarijo in združijo veje, celo večkrat na dan. Razumevanje in osvojitev te lastnosti vam da zmogljivo in unikatno orodje ter lahko v celoti spremeni način vašega razvoja.
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 Kaj je Git?, Git ne shranjuje podatkov kot serije skupkov sprememb ali razlik, vendar namesto tega kot serije posnetkov.
Ko naredite potrditev, Git shrani objekt potrditve, ki vsebuje kazalec k posnetku vsebine, ki ste jo dali v področje priprave. Ta objekt vsebuje tudi avtorjevo ime in e-pošto, sporočilo, ki ste ga vpisali, in kazalce k potrditvi ali potrditvam, ki so neposredno prišle pred to potrditvijo (njeno nadrejeno ali nadrejene): brez nadrejenih za začetno potrditev, ena nadrejena za običajno potrditev in več nadrejenih za potrditev, ki je rezultat združevanja dveh ali več vej.
Da to vizualiziramo, predpostavimo, da imate direktorij, ki vsebuje tri datoteke in vse daste v področje priprave in nato potrdite. Dajanje datotek v področje priprave izračuna kontrolno vsoto za vsako (zgoščena vrednost SHA-1, ki smo jo omenili v Kaj je Git?), shrani to različico datoteke v repozitorij Git (Git se sklicuje nanje kot blob) in doda to kontrolno vsoto v področje priprave:
$ git add README test.rb LICENSE
$ git commit -m 'Initial commit'
Ko ustvarite potrditev s pogonom git commit
, Git preveri kontrolne vsote za vsak poddirektorij (v tem primeru samo vrhnji direktorij projekta) in jih shrani kot drevesni objekt v repozitorij Git.
Git nato ustvari objekt potrditve, ki ima metapodatke in kazalec na vrhnje drevo projekta, da lahko ponovno ustvari posnetek, ko je treba.
Vaš repozitorij Git sedaj vsebuje pet objektov: tri blobe (vsak predstavlja vsebino ene izmed treh datotek), eno drevo, ki izpisuje vsebino direktorija in določa, katera imena datotek so shranjena kot blobi, in eno potrditev s kazalcem na to vrhnje drevo ter vse metapodatke potrditve.
Če naredite nekaj sprememb in nato ponovno potrdite, bo naslednja potrditev shranila kazalec k potrditvi, ki je prišla takoj pred tem.
Veja v Gitu je enostavno lahek prenosni kazalec k eni od teh potrditev.
Privzeto ime veje v Gitu je master
.
Ko začnete delati potrditve, imate dano vejo master
, ki kaže na zadnjo potrditev, ki ste jo naredili.
Vsakič, ko potrdite, se kazalec veje master
avtomatsko premakne naprej.
Opomba
|
Veja »master« v Gitu ni posebna veja.
Je točno taka kot katerakoli druga veja.
Edini razlog, da ima skoraj vsak repozitorij eno, je, da jo ukaz |
Ustvarjanje nove veje
Kaj se zgodi, ko ustvarite novo vejo?
No, to naredi za vas nov kazalec, ki se premika okoli.
Recimo, da želite ustvariti novo vejo imenovano testing
.
To naredite z ukazom git branch
:
$ git branch testing
To ustvari nov kazalec na isto potrditev, na kateri ste trenutno.
Kako Git ve, na kateri veji ste trenutno?
Ima poseben kazalec imenovan HEAD
.
Bodite pozorni, saj je to precej drugačno od zasnove HEAD
v drugih VCS-jih, ki ste ga morda vajeni, kot sta Subversion ali CVS.
V Gitu 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 pa tudi preklopil na to vejo.
To lahko enostavno pogledate, da poženete ukaz git log
, ki vam prikaže, kam kazalci veje kažejo.
Ta možnost se imenuje --decorate
.
$ git log --oneline --decorate
f30ab (HEAD -> master, testing) Add feature #32 - ability to add new formats to the central interface
34ac2 Fix bug #1328 - stack overflow under certain conditions
98ca9 Initial commit
Vidite lahko veji master
in testing
, ki sta ravno tam zraven potrditve f30ab
.
Preklapljanje med vejami
Da preklopite na obstoječo vejo, poženete ukaz git checkout
.
Preklopimo na novo vejo testing
:
$ git checkout testing
To prestavi HEAD
, da kaže na vejo testing
.
Kaj je pomembnost tega? Torej naredimo drugo potrditev:
$ vim test.rb
$ git commit -a -m 'Make a change'
To je zanimivo, ker se je sedaj vaša veja testing
premaknila naprej, vendar vaša veja master
še vedno kaže na potrditev, kjer ste bili, ko ste pognali git checkout
, da ste preklopili veje.
Preklopimo nazaj na vejo master
:
$ git checkout master
Opomba
|
git log ne prikaže vsakič vseh vejČe bi sedaj pognali Veja ni izginila; Git preprosto ne ve, da vas ta veja zanima, in poskuša prikazati tisto, kar misli, da vas zanima.
Drugače povedano, privzeto bo Da bi prikazali zgodovino sprememb za želeno vejo, jo morate izrecno določiti: |
Ta ukaz je naredil dve stvari.
Premaknil je kazalec HEAD nazaj na točko veje master
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 različice projekta.
V osnovi presname nazaj delo, ki ste ga naredili na vaši veji testing
, tako da lahko greste v drugačno smer.
Opomba
|
Preklapljanje vej spremeni datoteke v vašem delovnem direktoriju
Pomembno je opozoriti, da ko v Gitu preklopite veje, se datoteke v vašem delovnem direktoriju spremenijo. Če ste preklopili na starejšo vejo, bo vaš delovni direktorij prestavljen nazaj, da je videti tako, kot je prejšnjič, ko ste naredili potrditev na tisti veji. Če Git tega ne more narediti gladko, vam sploh ne bo dovolil preklopiti. |
Naredimo nekaj sprememb in ponovno potrdimo:
$ vim test.rb
$ git commit -a -m 'Make other changes'
Sedaj se je zgodovina vašega projekta spremenila (glejte sliko Različna zgodovina).
Ustvarili in preklopili ste na vejo, naredili nekaj dela na njej in nato preklopili nazaj na svojo glavno vejo ter naredili drugo delo.
Obe od teh sprememb sta izolirani v ločenih vejah: lahko preklopite nazaj in naprej med vejama in ju združite skupaj, ko ste pripravljeni.
In vse to ste naredili z enostavnimi ukazi branch
, checkout
in commit
.
To lahko enostavno pogledate tudi z ukazom git log
.
Če poženete git log --oneline --decorate --graph --all
, bo izpisal zgodovino vaših potrditev, prikazal, kje so kazalci vej in kako se je vaša zgodovina spremenila.
$ git log --oneline --decorate --graph --all
* c2b9e (HEAD, master) Make other changes
| * 87ab2 (testing) Make a change
|/
* f30ab Add feature #32 - ability to add new formats to the central interface
* 34ac2 Fix bug #1328 - stack overflow under certain conditions
* 98ca9 Initial commit of my project
Ker je veja v Gitu dejansko enostavna datoteka, ki vsebuje 40 znakovno kontrolno vsoto SHA-1 potrditve, kamor kaže, so veje ugodne za izdelavo in uničenje. Ustvarjanje nove veje je hitro in enostavno kakor napisati 41 bajtov v datoteko (40 znakov in nova vrstica).
To je v močnem nasprotju z načinom večine vej starejših orodij VCS, ki vključujejo kopiranje vseh datotek projekta v drug direktorij. To lahko vzame nekaj sekund ali celo minut, odvisno od velikosti projekta, kjer pa je proces v Gitu vedno takojšnji. Tudi ker snemamo nadrejene, ko potrjujemo, da najdemo ustrezno združevalno osnovo, saj je združevanje za nas avtomatično izvedeno in ga je v splošnem zelo enostavno narediti. Te lastnosti pomagajo spodbujati razvijalce, da pogostokrat ustvarijo in uporabijo veje.
Poglejmo, zakaj bi to morali tako narediti.
Opomba
|
Ustvarjanje nove veje in istočasno preklapljanje nanjo
Običajno je narediti novo vejo in istočasno želeti preklopiti nanjo — to se lahko naredi v eni operaciji z |
Opomba
|
Od različice Git 2.23 naprej lahko uporabite
|