-
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
10.3 Notranjost Gita - Reference Git
Reference Git
Če vas zanima ogled zgodovine vašega repozitorija, katera je dosegljiva od potrditve 1a410e
, bi lahko zagnali nekaj podobnega kot git log 1a410e
, da bi prikazali to zgodovino, vendar bi si še vedno morali zapomniti, da je 1a410e
tista potrditev, ki jo želite uporabiti kot začetno točko za to zgodovino.
Namesto tega bi bilo lažje, če bi imeli datoteko, v kateri bi lahko shranili tisto vrednost SHA-1 pod preprostim imenom, tako da bi lahko uporabili to preprosto ime namesto surove vrednosti SHA-1.
V Gitu se ta preprosta imena imenujejo »reference« ali »refs«; datoteke, ki vsebujejo te vrednosti SHA-1, lahko najdete v imeniku .git/refs
.
V trenutnem projektu ta imenik ne vsebuje datotek, vendar vsebuje preprosto strukturo:
$ find .git/refs
.git/refs
.git/refs/heads
.git/refs/tags
$ find .git/refs -type f
Da ustvarite novo referenco, ki si vam bo pomagala zapomniti, kje je vaša zadnja potrditev, lahko teoretično naredite nekaj tako preprostega kot to:
$ echo 1a410efbd13591db07496601ebc7a059dd55cfe9 > .git/refs/heads/master
Sedaj lahko v svojih ukazih Git uporabite glavno referenco, ki ste jo pravkar ustvarili namesto vrednosti SHA-1:
$ git log --pretty=oneline master
1a410efbd13591db07496601ebc7a059dd55cfe9 Third commit
cac0cab538b970a37ea1e769cbbde608743bc96d Second commit
fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit
Ne spodbujamo vas, da neposredno urejate datoteke z referencami; namesto tega Git ponuja varnejši ukaz git update-ref
, če želite posodobiti referenco:
$ git update-ref refs/heads/master 1a410efbd13591db07496601ebc7a059dd55cfe9
To je v bistvu tisto, kar je veja v Gitu: preprost kazalnik ali referenca na konico delovne veje. Če želite ustvariti vejo nazaj pri drugi potrditvi, lahko to storite takole:
$ git update-ref refs/heads/test cac0ca
Vaša veja bo vsebovala samo delo od tiste potrditve navzdol:
$ git log --pretty=oneline test
cac0cab538b970a37ea1e769cbbde608743bc96d Second commit
fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit
Sedaj je vaša podatkovna baza Git konceptualno videti nekako takole:
![Objekti direktorija Git, ki vključujejo glavne reference veje](png/data-model-4.png)
Ko zaženete ukaze, kot je git branch <branch>
, Git v bistvu zažene ukaz update-ref
, da doda SHA-1 zadnje potrditve vaše trenutne veje v katero koli novo referenco, ki jo želite ustvariti.
HEAD
Vprašanje je zdaj, kako Git ve za SHA-1 zadnje potrditve, ko zaženete git branch <branch>
?
Odgovor je datoteka HEAD.
Običajno je datoteka HEAD simbolična referenca na trenutno vejo. S simbolično referenco mislimo, da vsebuje kazalec na drugo referenco, v nasprotju z običajno referenco.
Vendar pa v nekaterih redkih primerih datoteka HEAD vsebuje vrednost SHA-1 objekta Git. To se zgodi, ko izvlečete oznako, potrditev, ali oddaljeno vejo, kar postavi vaš repozitorij v stanje ločene glave.
Če pogledate datoteko, boste običajno videli nekaj takega:
$ cat .git/HEAD
ref: refs/heads/master
Če poženete git checkout test
, bo Git posodobil datoteko, da je videti nekako takole:
$ cat .git/HEAD
ref: refs/heads/test
Ko zaženete git commit
, to ustvari objekt potrditve in določi nadrejeno tega objekta potrditve na vrednost SHA-1, na katero referenca v datoteki HEAD kaže.
Datoteko lahko uredite tudi ročno, vendar obstaja tudi tukaj varnejši ukaz, ki to omogoča: git symbolic-ref
.
Vrednost datoteke HEAD lahko preberete s tem ukazom:
$ git symbolic-ref HEAD
refs/heads/master
Z uporabo istega ukaza lahko tudi nastavite vrednost HEAD:
$ git symbolic-ref HEAD refs/heads/test
$ cat .git/HEAD
ref: refs/heads/test
Simbolične reference izven stila referenc ne morete nastaviti:
$ git symbolic-ref HEAD test
fatal: Refusing to point HEAD outside of refs/
Oznake
Ravno smo končali razpravo o treh glavnih vrstah objektov v Gitu (blobi, drevesa in potrditve), vendar obstaja še četrti objekt. Objekt oznake je zelo podoben objektu potrditve — vsebuje označevalca, datum, sporočilo in kazalec. Glavna razlika je v tem, da oznaka običajno kaže na potrditev namesto na drevo. Podobna je referenci na vejo, vendar se nikoli ne premika — vedno kaže na isto potrditev, vendar mu da prijaznejše ime.
Kot smo razpravljali v Osnove Git, obstajata dve vrsti oznak: anotirane in enostavne. Enostavno oznako lahko ustvarite z zagonom nečesa takega:
$ git update-ref refs/tags/v1.0 cac0cab538b970a37ea1e769cbbde608743bc96d
To je vse, kar je lahko enostavna oznaka — referenca, ki se nikoli ne premika.
Anotirana oznaka pa je bolj zapletena.
Če ustvarite anotirano oznako, Git ustvari objekt oznake in nato zapiše referenco, da kaže nanjo namesto neposredno na potrditev.
To lahko vidite, če ustvarite anotirano oznako (z uporabo možnosti -a
):
$ git tag -a v1.1 1a410efbd13591db07496601ebc7a059dd55cfe9 -m 'Test tag'
Tu je vrednost SHA-1 objekta, ki ga to ustvari:
$ cat .git/refs/tags/v1.1
9585191f37f7b0fb9444f35a9bf50de191beadc2
Sedaj poženite git cat-file -p
na tej vrednosti SHA-1:
$ git cat-file -p 9585191f37f7b0fb9444f35a9bf50de191beadc2
object 1a410efbd13591db07496601ebc7a059dd55cfe9
type commit
tag v1.1
tagger Scott Chacon <schacon@gmail.com> Sat May 23 16:48:58 2009 -0700
Test tag
Opazite, da vnos objekta kaže na vrednost SHA-1 potrditve, ki ste jo označili. Prav tako opazite, da ni potrebno, da kaže na potrditev; lahko označite kateri koli objekt Git. V izvorni kodi Git je na primer vzdrževalec dodal svoj javni ključ GPG kot objekt blob in ga nato označil. Javni ključ si lahko ogledate tako, da v klonu repozitorija Git zaženete to:
$ git cat-file blob junio-gpg-pub
Tudi repozitorij jedra Linux ima objekt oznake, ki ne kaže na potrditev — prva ustvarjena oznaka kaže na začetno drevo uvoza izvorne kode.
Daljave
Tretja vrsta reference, ki jo boste videli, je oddaljena referenca.
Če dodate oddaljeni vir in nanj potisnete, Git shrani vrednost, ki ste jo nazadnje potisnili na ta oddaljeni vir za vsako vejo v mapi .git/refs/remotes
.
Na primer, lahko dodate oddaljeni vir, imenovan origin
, in nanj potisnete svojo vejo master
:
$ git remote add origin git@github.com:schacon/simplegit-progit.git
$ git push origin master
Counting objects: 11, done.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (7/7), 716 bytes, done.
Total 7 (delta 2), reused 4 (delta 1)
To git@github.com:schacon/simplegit-progit.git
a11bef0..ca82a6d master -> master
Nato pa lahko preverite, katera različica veje master na oddaljenem strežniku origin
je bila nazadnje poslana, tako da preverite datoteko refs/remotes/origin/master
:
$ cat .git/refs/remotes/origin/master
ca82a6dff817ec66f44342007202690a93763949
Oddaljene reference se razlikujejo od vej (reference refs/heads
) predvsem v tem, da so obravnavane kot samo za branje.
Z git checkout
se jih lahko izvleče, vendar Git ne bo simbolno referenciral HEAD nanje, zato jih nikoli ne boste posodobili z ukazom commit
.
Git jih upravlja kot zaznamke zadnjega znanega stanja, kjer so bile te veje na teh strežnikih.