Chapters ▾ 2nd Edition

10.3 Git Internals - Git-verwysings (Git References)

Git-verwysings (Git References)

As jy daarin belangstel om die geskiedenis van jou bewaarplek te sien wat bereikbaar is vanaf vaslegging, sê maar, 1a410e, kan jy iets soos git log 1a410e uitvoer om daardie geskiedenis te vertoon, maar jy sal steeds moet onthou dat 1a410e die vaslegging is wat jy as die beginpunt vir daardie geskiedenis wil gebruik. In plaas daarvan sou dit makliker wees as jy 'n lêer het waarin jy daardie SHA-1-waarde onder 'n eenvoudige naam kan stoor, sodat jy daardie eenvoudige naam kan gebruik eerder as die rou SHA-1-waarde.

In Git word hierdie eenvoudige name “verwysings” (references) of “refs” genoem; jy kan die lêers wat daardie SHA-1-waardes bevat in die .git/refs-gids vind. In die huidige projek bevat hierdie gids geen lêers nie, maar dit bevat wel 'n eenvoudige struktuur:

$ find .git/refs
.git/refs
.git/refs/heads
.git/refs/tags
$ find .git/refs -type f

Om 'n nuwe verwysing te skep wat jou sal help onthou waar jou nuutste vaslegging is, kan jy tegnies iets so eenvoudig soos dit doen:

$ echo 1a410efbd13591db07496601ebc7a059dd55cfe9 > .git/refs/heads/master

Nou kan jy die kop-verwysing (head reference) wat jy pas geskep het in plaas van die SHA-1-waarde in jou Git-opdragte gebruik:

$ git log --pretty=oneline master
1a410efbd13591db07496601ebc7a059dd55cfe9 Third commit
cac0cab538b970a37ea1e769cbbde608743bc96d Second commit
fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit

Jy word nie aangemoedig om die verwysingslêers direk te redigeer nie; in plaas daarvan verskaf Git die veiliger opdrag git update-ref om dit te doen as jy 'n verwysing wil opdateer:

$ git update-ref refs/heads/master 1a410efbd13591db07496601ebc7a059dd55cfe9

Dit is basies wat 'n tak (branch) in Git is: 'n eenvoudige wyser of verwysing na die kop van 'n lyn van werk. Om 'n tak terug by die tweede vaslegging te skep, kan jy dit doen:

$ git update-ref refs/heads/test cac0ca

Jou tak sal slegs werk van daardie vaslegging af ondertoe bevat:

$ git log --pretty=oneline test
cac0cab538b970a37ea1e769cbbde608743bc96d Second commit
fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit

Nou lyk jou Git-databasis konseptueel min of meer so:

Git directory objects with branch head references included
Figure 189. Git-gids objekte met tak-kop-verwysings ingesluit

Wanneer jy opdragte soos git branch <tak> uitvoer, voer Git basies daardie update-ref-opdrag uit om die SHA-1 van die laaste vaslegging van die tak waarop jy is, by te voeg in watter nuwe verwysing jy ook al wil skep.

Die HEAD (The HEAD)

Die vraag is nou, wanneer jy git branch <tak> uitvoer, hoe weet Git wat die SHA-1 van die laaste vaslegging is? Die antwoord is die HEAD-lêer.

Gewoonlik is die HEAD-lêer 'n simboliese verwysing na die tak waarop jy tans is. Met simboliese verwysing bedoel ons dat, anders as 'n normale verwysing, dit 'n wyser na 'n ander verwysing bevat.

In sommige seldsame gevalle kan die HEAD-lêer egter die SHA-1-waarde van 'n Git-objek bevat. Dit gebeur wanneer jy 'n merker (tag), vaslegging, of afgeleë tak (remote branch) uittrek (checkout), wat jou bewaarplek in 'n "losgemaakte HEAD" (detached HEAD) toestand plaas.

As jy na die lêer kyk, sal jy normaalweg iets soos dit sien:

$ cat .git/HEAD
ref: refs/heads/master

As jy git checkout test uitvoer, dateer Git die lêer op om so te lyk:

$ cat .git/HEAD
ref: refs/heads/test

Wanneer jy git commit uitvoer, skep dit die vasleggingsobjek, wat die ouer van daardie vasleggingsobjek spesifiseer as watter SHA-1-waarde ook al die verwysing in HEAD na wys.

Jy kan ook hierdie lêer handmatig redigeer, maar weereens bestaan daar 'n veiliger opdrag om dit te doen: git symbolic-ref. Jy kan die waarde van jou HEAD via hierdie opdrag lees:

$ git symbolic-ref HEAD
refs/heads/master

Jy kan ook die waarde van HEAD instel deur dieselfde opdrag te gebruik:

$ git symbolic-ref HEAD refs/heads/test
$ cat .git/HEAD
ref: refs/heads/test

Jy kan nie 'n simboliese verwysing buite die refs-styl instel nie:

$ git symbolic-ref HEAD test
fatal: Refusing to point HEAD outside of refs/

Merkers (Tags)

Ons het pas klaar Git se drie hoof objektipe (blobs, trees (bome) en commits (vasleggings)) bespreek, maar daar is 'n vierde. Die merker-objek is baie soos 'n vasleggingsobjek — dit bevat 'n merker (tagger), 'n datum, 'n boodskap, en 'n wyser. Die hoofverskil is dat 'n merker-objek oor die algemeen na 'n vaslegging wys eerder as na 'n boom. Dit is soos 'n tak-verwysing, maar dit beweeg nooit nie — dit wys altyd na dieselfde vaslegging, maar gee dit 'n vriendeliker naam.

Soos bespreek in Git Basics, is daar twee tipes merkers: geannoteer en liggewig. Jy kan 'n liggewig merker maak deur iets soos dit uit te voer:

$ git update-ref refs/tags/v1.0 cac0cab538b970a37ea1e769cbbde608743bc96d

Dit is al wat 'n liggewig merker is — 'n verwysing wat nooit beweeg nie. 'n Geannoteerde merker is egter meer kompleks. As jy 'n geannoteerde merker skep, skep Git 'n merker-objek en skryf dan 'n verwysing om daarna te wys eerder as direk na die vaslegging. Jy kan dit sien deur 'n geannoteerde merker te skep (met behulp van die -a opsie):

$ git tag -a v1.1 1a410efbd13591db07496601ebc7a059dd55cfe9 -m 'Test tag'

Hier is die objek se SHA-1-waarde wat dit geskep het:

$ cat .git/refs/tags/v1.1
9585191f37f7b0fb9444f35a9bf50de191beadc2

Voer nou git cat-file -p uit op daardie SHA-1-waarde:

$ 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

Let op dat die objek-inskrywing wys na die vaslegging SHA-1-waarde wat jy gemerk het. Let ook op dat dit nie na 'n vaslegging hoef te wys nie; jy kan enige Git-objek merk. In die Git-bronkode, byvoorbeeld, het die instandhouer hul GPG publieke sleutel as 'n blob-objek bygevoeg en dit dan gemerk. Jy kan die publieke sleutel besigtig deur dit in 'n kloon van die Git-bewaarplek uit te voer:

$ git cat-file blob junio-gpg-pub

Die Linux-kern-bewaarplek het ook 'n merker-objek wat nie na 'n vaslegging wys nie — die eerste merker wat geskep is, wys na die aanvanklike boom van die invoer van die bronkode.

Afgeleë Verwysings (Remotes)

Die derde tipe verwysing wat jy sal sien, is 'n afgeleë verwysing (remote reference). As jy 'n remote byvoeg en soontoe push, stoor Git die waarde wat jy laas na daardie remote gepush het vir elke tak in die refs/remotes-gids. Byvoorbeeld, jy kan 'n remote genaamd origin byvoeg en jou master-tak soontoe push:

$ 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

Dan kan jy sien wat die master-tak op die origin-remote was die laaste keer wat jy met die bediener gekommunikeer het, deur die refs/remotes/origin/master-lêer na te gaan:

$ cat .git/refs/remotes/origin/master
ca82a6dff817ec66f44342007202690a93763949

Afgeleë verwysings verskil van takke (refs/heads verwysings) hoofsaaklik daarin dat hulle as leesalleen (read-only) beskou word. Jy kan 'n git checkout na een doen, maar Git sal nie simbolies HEAD na een verwys nie, so jy sal dit nooit met 'n commit-opdrag opdateer nie. Git bestuur hulle as boekmerke na die laaste bekende toestand van waar daardie takke op daardie bedieners was.