Chapters ▾ 2nd Edition

10.3 Git bakom kulisserna - Git-referenser

Git-referenser

Om du vill se historiken i ditt kodförråd som kan nås från en incheckning, säg 1a410e, kan du köra något i stil med git log 1a410e för att visa den historiken, men du måste ändå komma ihåg att 1a410e är incheckningen du vill använda som startpunkt. I stället vore det enklare om du hade en fil där du kunde lagra SHA‑1‑värdet under ett enkelt namn så att du kan använda det enkla namnet i stället för det råa SHA‑1‑värdet.

I Git kallas dessa enkla namn “referenser” eller “refs”; du hittar filerna som innehåller dessa SHA‑1‑värden i katalogen .git/refs. I det aktuella projektet innehåller denna katalog inga filer, men den innehåller en enkel struktur:

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

För att skapa en ny referens som hjälper dig att komma ihåg var din senaste incheckning ligger kan du rent tekniskt göra något så här enkelt:

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

Nu kan du använda huvudreferensen du just skapade i stället för SHA‑1‑värdet i dina Git‑kommandon:

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

Du bör inte redigera referensfilerna direkt; i stället ger Git det säkrare kommandot git update-ref om du vill uppdatera en referens:

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

Det är i grunden vad en gren i Git är: en enkel pekare eller referens till toppen av en utvecklingslinje. För att skapa en gren tillbaka vid den andra incheckningen kan du göra så här:

$ git update-ref refs/heads/test cac0ca

Din gren kommer bara att innehålla arbete från den incheckningen och nedåt:

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

Nu ser din Git‑databas konceptuellt ut ungefär så här:

Git‑katalogobjekt med grenhuvudreferenser
Figur 174. Git‑katalogobjekt med grenhuvudreferenser

När du kör kommandon som git branch <branch> kör Git i praktiken kommandot update-ref för att lägga in SHA‑1‑värdet för den senaste incheckningen i grenen du står på i den referens du vill skapa.

HEAD

Frågan nu är: när du kör git branch <branch>, hur vet Git SHA‑1:an för den senaste incheckningen? Svaret är HEAD‑filen.

Vanligtvis är HEAD‑filen en symbolisk referens till grenen du är på. Med symbolisk referens menar vi att den, till skillnad från en vanlig referens, innehåller en pekare till en annan referens.

I vissa sällsynta fall kan HEAD‑filen dock innehålla SHA‑1‑värdet för ett Git‑objekt. Detta händer när du växlar till en tagg, incheckning eller fjärrgren, vilket försätter ditt kodförråd i ett frikopplat HEAD‑läge ("frikopplad HEAD").

Om du tittar på filen ser du normalt något i stil med detta:

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

Om du kör git checkout test uppdaterar Git filen så att den ser ut så här:

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

När du kör git commit skapar Git incheckningsobjektet och anger att föräldern till det objektet ska vara vilket SHA‑1‑värde som referensen i HEAD pekar på.

Du kan också redigera filen manuellt, men återigen finns det ett säkrare kommando för det: git symbolic-ref. Du kan läsa värdet på HEAD med detta kommando:

$ git symbolic-ref HEAD
refs/heads/master

Du kan också sätta värdet på HEAD med samma kommando:

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

Du kan inte sätta en symbolisk referens utanför refs‑stilen:

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

Taggar

Vi avslutade just diskussionen om Gits tre huvudsakliga objekttyper (blobbar, träd och incheckningar), men det finns en fjärde. Taggobjektet är mycket likt ett incheckningsobjekt – det innehåller en taggare, ett datum, ett meddelande och en pekare. Den största skillnaden är att ett taggobjekt i regel pekar på en incheckning i stället för ett träd. Det är som en grenreferens, men den flyttar sig aldrig – den pekar alltid på samma incheckning men ger den ett mer lättläst namn.

Som diskuterats i Grunderna i Git finns det två typer av taggar: annoterade och lättviktiga. Du kan skapa en lättviktig tagg genom att köra något i den här stilen:

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

Det är allt en lättviktig tagg är – en referens som aldrig flyttar sig. En annoterad tagg är däremot mer komplex. Om du skapar en annoterad tagg skapar Git ett taggobjekt och skriver sedan en referens som pekar på det i stället för direkt på incheckningen. Du kan se detta genom att skapa en annoterad tagg (med alternativet -a):

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

Här är objektets SHA‑1‑värde som skapades:

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

Kör nu git cat-file -p på det SHA‑1‑värdet:

$ 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

Observera att objektraden pekar på SHA‑1‑värdet för incheckningen du taggade. Notera också att den inte måste peka på en incheckning; du kan tagga vilket Git‑objekt som helst. I Gits källkod har till exempel förvaltaren lagt till sin publika GPG‑nyckel som ett blob‑objekt och sedan taggat det. Du kan se den publika nyckeln genom att köra detta i en klon av Git‑kodförrådet:

$ git cat-file blob junio-gpg-pub

Linuxkärnans kodförråd har också ett taggobjekt som inte pekar på en incheckning – den första taggen som skapades pekar på det första trädet i importen av källkoden.

Fjärrreferenser

Den tredje typen av referens du ser är en fjärrreferens. Om du lägger till ett fjärrkodförråd och skickar upp till det lagrar Git värdet du senast skickade upp till fjärrkodförrådet för varje gren i katalogen refs/remotes. Du kan till exempel lägga till ett fjärrkodförråd som heter origin och skicka din master‑gren till det:

$ 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

Sedan kan du se vad grenen master i fjärrkodförrådet origin var senast du kommunicerade med servern genom att kontrollera filen refs/remotes/origin/master:

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

Fjärrreferenser skiljer sig från grenar (referenser under refs/heads) främst genom att de betraktas som skrivskyddade. Du kan växla till en sådan med git checkout, men Git kommer inte att symboliskt referera HEAD till den, så du kommer aldrig att uppdatera den med ett commit‑kommando. Git hanterar dem som bokmärken för det senast kända läget för var de grenarna fanns på dessa servrar.