10.3 Git Binnenwerk - Git Referenties

De vraag is nu, als je git branch <branchnaam> aanroept, hoe weet Git de SHA-1 van de laatste commit? Het antwoord is het HEAD bestand.

Normaalgesproken is het HEAD bestand een symbolische referentie naar de branch waar je op dit moment op zit. Met symbolische referentie bedoelen we dat, in tegenstelling tot een normale referentie, het een verwijzing naar een andere referentie.

Echter, in enkele uitzonderlijke gevallen kan het HEAD bestand de SHA-1 waarde bevatten van een git-object. Dit gebeurt als een tag, commit of remote branch uitcheckt, wat je repository in een "detached HEAD" staat brengt.

Als je naar het bestand kijkt, zie je normaalgesproken zoiets als dit:

Als je git checkout test aanroept, werkt Git het bestand bij om er zo uit te zien:

Als je git commit aanroept, wordt het commit object aangemaakt, waarbij de ouder van dat commit object wordt gespecificeerd door de SHA-1 waarde die staat in de referentie waar HEAD op dat moment naar verwijst.

Je kunt dit bestand ook handmatig bijwerken, maar alweer is er een veiliger comando om dit te doen: symbolic-ref. Je kunt de waarde van je HEAD met dit commando lezen:

Je kunt ook de waarde van HEAD bepalen met het zelfde commando:

Je kunt geen symbolische referentie waarde invullen die niet voldoet aan de de refs-stijl:

We zijn zojuist geëindigt met het bespreken van de drie hoofd objecttypen van Git (blobs, trees en commits), maar er is nog een vierde. Het tag object lijkt erg op een commit object — het bevat een tagger, een datum, een bericht en een verwijzing. Het belangrijkste verschil is dat een tag object over het algemeen verwijst naar een commit in plaats van een boom. Het lijkt op een branch referentie, maar het zal nooit bewegen — het verwijst altijd naar dezelfde commit, maar geeft het een vriendelijkere naam.

Zoals besproken in Git Basics, zijn er twee soorten tags: geannoteerd en lichtgewicht. Je kunt een lichtgewicht tag aanmaken door iets als het volgende aan te roepen:

Dat is alles wat een lichtgewicht tag is — een referentie dat nooit zal bewegen. Een geannoteerde tag is echter veel complexer. Als je een geannoteerde tag aanmaakt, maakt Git een tag object en schrijft daarna een referentie die daarnaar verwijst, in plaats van direct te verwijzen naar de commit. Je kunt dit zien door een geannoteerde tag aan te maken (met de -a optie):

Hier is de SHA-1 waarde van het object die is aangemaakt:

En roep nu het git cat-file -p commando aan op die SHA-1 waarde;

Merk op dat vermelding van het object wijst naar de SHA-1 waarde van de commit die je hebt getagged. Merk ook op dat het niet perse hoeft te verwijzen naar een commit; je kunt elke Git object taggen. In de broncode van Git, bijvoorbeeld, heeft de onderhouder hun GPG publieke sleutel als een blob object toegevoegd en deze toen getagged. Je kunt de publieke sleutel bekijken door het volgende aan te roepen in een cloon van de Git repository:

De Linux kernel repository heeft ook een tag die niet naar een commit wijst — de eerste tag die gemaakt is verwijst naar de initiële tree van de import van de broncode.

Het derde type referentie die je zult zien is een remote referentie. Als je een remote toevoegt en ernaar pusht, slaat Git voor elke de waarde die je het laatst naar die remote hebt gepusht in de refs/remotes directory. Bijvoorbeeld, je kunt een remote genaamd origin toevoegen en daar je master-branch naar pushen:

Je kunt zien wat de master-branch op de origin remote was op met moment dat je voor het laatst met de server hebt gecommuniceerd, door het refs/remotes/origin/master bestand te bekijken:

Referenties van remotes verschillen van branches (refs/heads referenties) voornamelijk door het feit dat ze als alleen-lezen worden beschouwd. Je kunt naar een git checkout doen, maar Git zal HEAD nooit naar een laten verwijzen, dus je zult er nooit een kunnen bijwerken met een commit commando. Git gebruikt ze als boekleggers naar de laatst bekende staat van waar deze branches op stonden op die servers.