10.2 Git bakom kulisserna - Git-objekt

Nästa typ av Git‑objekt vi tittar på är trädet, som löser problemet med att lagra filnamnet och också låter dig lagra en grupp filer tillsammans. Git lagrar innehåll på ett sätt som liknar ett UNIX‑filsystem, men lite förenklat. Allt innehåll lagras som träd‑ och blob‑objekt, där träd motsvarar UNIX‑katalogposter och blobbar motsvarar ungefär inoder eller filinnehåll. Ett enskilt trädobjekt innehåller en eller flera poster, där varje post är SHA‑1‑summan för en blob eller ett underträd tillsammans med tillhörande läge, typ och filnamn. Låt oss till exempel säga att du har ett projekt där det senaste trädet ser ut ungefär så här:

Syntaxen master^{tree} anger trädobjektet som pekas på av den senaste incheckningen på din master‑gren. Observera att underkatalogen lib inte är en blob utan en pekare till ett annat träd:

Konceptuellt ser de data Git lagrar ut ungefär så här:

Du kan ganska enkelt skapa ditt eget träd. Git skapar normalt ett träd genom att ta tillståndet i din köyta eller index och skriva en serie trädobjekt utifrån det. För att skapa ett trädobjekt måste du alltså först sätta upp ett index genom att köa några filer. För att skapa ett index med en enda post – den första versionen av din fil test.txt – kan du använda lågnivåkommandot git update-index. Du använder detta kommando för att manuellt lägga till den tidigare versionen av filen test.txt i en ny köyta. Du måste skicka alternativet --add eftersom filen ännu inte finns i din köyta (du har inte ens en köyta uppsatt än) och --cacheinfo eftersom filen du lägger till inte finns i din katalog utan i din databas. Sedan anger du läge, SHA‑1 och filnamn:

I det här fallet anger du läget 100644, vilket betyder att det är en vanlig fil. Andra alternativ är 100755, vilket betyder att det är en körbar fil, och 120000, som anger en symbolisk länk. Läget kommer från vanliga UNIX‑lägen men är mycket mindre flexibelt – dessa tre lägen är de enda som är giltiga för filer (blobbar) i Git (även om andra lägen används för kataloger och submoduler).

Nu kan du använda git write-tree för att skriva ut köytan till ett trädobjekt. Ingen -w‑flagga behövs – att anropa kommandot skapar automatiskt ett trädobjekt från indexets tillstånd om det trädet ännu inte finns:

Du kan också verifiera att detta är ett trädobjekt med samma git cat-file‑kommando som du såg tidigare:

Nu skapar du ett nytt träd med den andra versionen av test.txt och en ny fil också:

Din köyta har nu den nya versionen av test.txt samt den nya filen new.txt. Skriv ut det trädet (genom att registrera tillståndet i köytan eller indexet som ett trädobjekt) och se hur det ser ut:

Observera att detta träd har både filposter och att SHA‑1‑summan för test.txt är “version 2”‑SHA‑1‑summan från tidigare (1f7a7a). Bara för att prova lägger du till det första trädet som en underkatalog i detta. Du kan läsa in träd i din köyta genom att anropa git read-tree. I det här fallet kan du läsa in ett befintligt träd i köytan som ett underträd genom att använda alternativet --prefix med detta kommando:

Om du skapade en arbetskatalog från det nya träd du just skrev skulle du få de två filerna på toppnivån i arbetskatalogen och en underkatalog som heter bak som innehåller den första versionen av filen test.txt. Du kan tänka på den data Git innehåller för dessa strukturer ungefär så här:

Om du har gjort allt ovan har du nu tre träd som representerar de olika ögonblicksbilder av ditt projekt som du vill spåra, men det tidigare problemet kvarstår: du måste komma ihåg alla tre SHA‑1‑värden för att kunna återkalla ögonblicksbilderna. Du har heller ingen information om vem som sparade ögonblicksbilderna, när de sparades eller varför de sparades. Det är den grundläggande informationen som incheckningsobjektet lagrar åt dig.

För att skapa ett incheckningsobjekt anropar du git commit-tree och anger ett enda träd‑SHA‑1 och vilka incheckningsobjekt som i förekommande fall direkt föregick det. Börja med det första trädet du skrev:

Nu kan du titta på ditt nya incheckningsobjekt med git cat-file:

Formatet för ett incheckningsobjekt är enkelt: det anger toppnivåträdet för projektets ögonblicksbild vid den tidpunkten; föräldraincheckningar om det finns några (incheckningsobjektet ovan har inga föräldrar); författar-/incheckarinformation (som använder dina user.name‑ och user.email‑inställningar samt en tidsstämpel); en tom rad; och sedan incheckningsmeddelandet.

Därefter skriver du de andra två incheckningsobjekten, där varje objekt refererar till incheckningen som kom direkt före den:

Var och en av de tre incheckningsobjekten pekar på ett av de tre ögonblicksbildsträd du skapade. Intressant nog har du nu en riktig Git‑historik som du kan se med kommandot git log, om du kör det på den senaste incheckningens SHA‑1:

Toppen. Du har just gjort lågnivåoperationerna för att bygga upp en Git‑historik utan att använda några av gränssnittskommandona. I stort sett är det här vad Git gör när du kör git add och git commit: lagrar blobbar för ändrade filer, uppdaterar indexet, skriver träd och skapar incheckningsobjekt som pekar på toppnivåträd och föregående incheckningar. Dessa tre huvudsakliga Git‑objekt – blobben, trädet och incheckningen – lagras initialt som separata filer i din .git/objects‑katalog. Här är alla objekt i exempelkatalogen nu, kommenterade med vad de lagrar:

Om du följer alla interna pekare får du en objektgraf som ser ut ungefär så här:

Vi nämnde tidigare att det finns ett huvud som lagras tillsammans med varje objekt du checkar in i Git‑objektdatabasen. Låt oss kort se hur Git lagrar sina objekt. Du får se hur man lagrar ett blob‑objekt – i det här fallet strängen “what is up, doc?” – interaktivt i Ruby‑skriptspråket.

Du kan starta interaktivt Ruby‑läge med kommandot irb:

Git konstruerar först ett huvud som börjar med att identifiera objektets typ – i det här fallet en blob. Till den första delen av huvudet lägger Git till ett blanksteg följt av innehållets storlek i byte och lägger sedan till en avslutande nollbyte:

Git slår ihop huvudet och det ursprungliga innehållet och beräknar sedan SHA‑1‑kontrollsumman av det nya innehållet. Du kan beräkna SHA‑1‑värdet för en sträng i Ruby genom att inkludera SHA1‑digest‑biblioteket med kommandot require och sedan anropa Digest::SHA1.hexdigest() med strängen:

Låt oss jämföra det med utdata från git hash-object. Här använder vi echo -n för att undvika att lägga till en radbrytning i indata.

Git komprimerar det nya innehållet med zlib, vilket du kan göra i Ruby med zlib‑biblioteket. Först behöver du kräva biblioteket och sedan köra Zlib::Deflate.deflate() på innehållet:

Till sist skriver du ditt zlib‑komprimerade innehåll till ett objekt på disk. Du bestämmer sökvägen till objektet du vill skriva ut (de två första tecknen i SHA‑1‑värdet är underkatalognamnet och de sista 38 tecknen är filnamnet i den katalogen). I Ruby kan du använda funktionen FileUtils.mkdir_p() för att skapa underkatalogen om den inte finns. Öppna sedan filen med File.open() och skriv ut det tidigare zlib‑komprimerade innehållet till filen med ett write()‑anrop på den resulterande filhandtaget:

Låt oss kontrollera innehållet i objektet med git cat-file:

Det var allt – du har skapat ett giltigt Git‑blob‑objekt.

Alla Git‑objekt lagras på samma sätt, bara med olika typer – i stället för strängen blob kommer huvudet att börja med commit eller tree. Dessutom kan blob‑innehållet vara nästan vad som helst, men innehållet i incheckning‑ och träd‑objekt är mycket strikt formaterat.