10.2 Git Binnenwerk - Git objecten

Het volgende type waar we naar gaan kijken is de tree, wat het probleem oplost van het opslaan van bestandsnamen en je ook in staat stelt om een groep van bestanden bij elkaar op te slaan. Git slaat de inhoud op een manier die vergelijkbaar is met een UNIX bestandssysteem, maar wat versimpeld. Alle inhoud wordt opgeslagen als tree en blob objecten, waarbij trees overeenkomen met UNIX directory entries en blobs min of meer overeenkomen met inodes of bestandsinhoud. Een enkele tree object bevat een of meer entries, elk daarvan is de SHA-1 hash van een blob of subtree met de bijbehorende mode, type en bestandsnaam. Bijvoorbeeld, de meest recente tree in een project kan er ongeveer zo uitzien:

De master^{tree} syntax geeft het tree object aan waarnaar wordt verwezen door de laatste commit op je master-branch. Merk op dat de lib subdirectory geen blob is, maar een verwijzing naar een andere tree:

Conceptueel zijn de gegevens die Git opslaat ongeveer dit:

Je kunt redelijk eenvoudig je eigen boom maken. Git maakt normaalgesproken een tree door de staat van je staging gebied of index te nemen en daarvan een reeks tree objects te maken. Dus, om een tree object te maken, moet je eerst een index opzetten door wat bestanden te stagen. Om een index te maken met een enkele ingang — de eerste versie van je test.txt bestand — kan je het plumbing commando git update-index gebruiken. Je gebruikt dit commando om kunstmatig de eerdere versie van het bestand test.txt aan een nieuwe staging gebied toe te voegen. Je moet het de optie --add doorgeven omdat het bestand nog niet bestaat in je staging gebied (je hebt nog niet eens een staging gebied ingericht) en --cacheinfo omdat het bestand dat je toevoegt in in je directory zit maar in je database. Daarna geef je de mode, SHA-1 en bestandsnaam op:

In dit geval geef je een mode 100644 op, wat aangeeft dat het een normaal bestand is. Andere opties zijn 100755, wat aangeeft dat het een uitvoerbaar bestand is; en 120000, wat een symbolische link aangeeft. De modus is afgeleid van normale UNIX modi maar het is minder flexibel — deze drie modi zijn de enige die geldig zijn voor bestanden (blobs) in Git (alhoewel andere modi worden gebruikt voor directories en submodules).

Nu kan je het git write-tree commando gebruiken om het staging gebied te schrijven naar een tree object. Hier is geen -w optie nodig — het aanroepen van write-tree maakt automatisch een tree object aan van de staat van de index als die tree nog niet bestaat:

Je kunt ook verifiëren dat dit een tree object is met hetzelfde git cat-file commando die je eerder gezien hebt:

Je gaat nu een nieuwe tree maken met de tweede versie van test.txt en ook nog een nieuw bestand:

Je staging gebied heeft nu de nieuwe versie van test.txt alsook het nieuwe bestand new.txt. Schrijf dat deze tree weg (sla de staat van het staging gebied of index op in een tree object) en kijk hoe dit eruit ziet:

Merk op dat deze tree beide bestands entries bevat en ook dat de test.txt SHA-1 gelijk aan de “versie 2” SHA-1 van eerder is (1f7a7a). Puur voor de lol, ga je de eerste tree als een subdirectory toevoegen in deze. Je kunt trees in je staging area lezen door git read-tree aan te roepen. In dit geval, kan je een bestaande tree als een subtree in je staging gebied lezen door de --prefix optie te gebruiken bij dit commando:

Als je een werk directory van de nieuwe tree maakt die je zojuist geschreven hebt, zou je de twee bestanden op het hoogste niveau van de werk directory krijgen en een subdirectory met de naam bak die de eerste versie van het test.txt bestand zou bevatten. Je kunt de gegevens die Git bevat voor deze structuren als volgt weergeven:

Je hebt drie trees die de verschillende snapshots weergeven van je project die je wilt volgen, maar het eerdere probleem blijft: je moet alle drie SHA-1 waarden onthouden om de snapshots te kunnen terughalen. Je hebt ook geen informatie over wie de snapshots heeft opgeslagen, wanneer ze zijn opgeslagen of waarom ze waren opgeslagen. Dit is de basis informatie die het commit object voor je opslaat.

Om een commit object te maken, roep je commit-tree aan en geef je een de SHA-1 van een enkele tree op en welke commit objecten, indien van toepassing, er direct aan vooraf gaan. Begin met de eerste tree die je geschreven hebt:

Je zult verschillende hash-waarden krijgen omdat er verschillen zijn in aanmaak tijd en auteur-gegevens. Vervang de commit en tag-hashwaarden verderop in dit hoofdstuk met je eigen checksums. Nu kan je naar je nieuwe commit object kijken met git cat-file:

Het formaat voor een commit object is eenvoudig: het geeft de tree op het hoogste niveau weer voor de snapshot van het project op dat punt; de commits van de ouder (het commit object beschreven hierboven heeft geen enkele ouder); de auteur/committer informatie (welke je user.name en user.email configuratie instellingen gebruikt en een timestamp); een blanko regel en dan het commit bericht.

Vervolgens ga je de andere twee commit objects schrijven, die elk naar de commit refereren die er direct aan vooraf ging:

Elk van de drie commit objecten verwijzen naar een van de drie snapshot trees die je gemaakt hebt. Gek genoeg, heb je nu een echte Git historie die je kunt bekijken met het git log commando, als je dit aanroept op de laatste SHA-1 commit:

Verbluffend. Je hebt zojuist de diepere niveau operaties uitgevoerd die een Git historie hebben opgebouwd, zonder gebruik te maken van een van de hogere commando’s. In essentie is dit wat Git doet als je de git add en git commit commando’s gebuikt — het slaat blobs op voor de bestanden die zijn gewijzigd, werkt de index bij, schrijft de trees weg en schrijft commit objecten weg die verwijzen naar de trees op het hoogste niveau en de commits die er direct aan vooraf zijn gegaan. Deze drie hoofd Git objecten — de blob, de tree en de commit worden initieel opgeslagen als aparte bestanden in je .git/objects directory. Hier zijn alle huidige objecten in de voorbeeld directory, met als commentaar wat ze opslaan:

Als je al de interne verwijzingen volgt, zal je een objectgraaf krijgen die er ongeveer zo uitziet:

We hebben eerder gezegd dat er een header wordt opgeslagen bij de inhoud. Laten we nu de tijd nemen om een kijkje te nemen hoe Git haar objecten opslaat. Je gaat zien hoe een blob object interactief wordt opgeslagen — in dit geval, de zin “what is up, doc?” — in de Ruby scripttaal.

Je kunt de interactieve Ruby modus starten met het irb commando:

Git stelt een header samen die begint met het type van het object, in dit geval een blob. Aan dat eerste gedeelte van de header voegt Git een spatie toe gevolgd door de lengte in bytes van de inhoud en tot slot een null byte:

Git plakt de header en de oorspronkelijke inhoud samen en berekent het SHA-1 controlegetal van die nieuwe inhoud. Je kunt de SHA-1 waarde van een tekenreeks in Ruby berekenen door de SHA1 digest library te includen met het require commando en daarna Digest::SHA1.hexdigest() aan te roepen met de tekenreeks:

Laten we dit vergelijken met de uitvoer van git hash-object. Hier gebruiken we echo -n om te voorkomen dat er een newline aan de invoer wordt toegevoegd.

Git comprimeert de nieuwe inhoud met zlib, wat je in Ruby kunt doen met de zlib library. Eerst moet je de library requiren en daarna Zlib::Deflate.deflate() aanroepen op de inhoud:

Als laatste schrijf je je zlib-deflated inhoud naar een object op schijf. Je bepaalt het pad van het object die je wilt schrijven (de eerste twee karakters van de SHA-1 waarde als de naam van de subdirectory, en de overige 38 karakters zijnde de bestandsnaam binnen die directory). In Ruby kan je de FileUtils.mkdir_p() functie gebruiken om de subdirectory aan te maken als die nog niet bestaat. Daarna open je het bestand met File.open() en schrijf je de eerder zlib-gecomprimeerde inhoud naar het bestand met een write() aanroep op de filehandle die je krijgt:

Laten we de inhoud van het object controleren met git cat-file:

Dat is alles - je hebt een valide Git blob object gemaakt.

Alle Git objecten worden op dezelfde manier opgeslagen, alleen met andere types - in plaats van de tekenreeks blob, begint de header met commit of tree. Daarnaast, alhoewel de inhoud van een blob zo ongeveer alles kan zijn, is de inhoud van een commit en tree zeer specifiek geformatteerd.