10.2 Git Internals - Git Objekte (Git Objects)

Die volgende tipe Git-objek wat ons sal ondersoek is die boom (tree), wat die probleem oplos om die lêernaam te stoor en jou ook toelaat om 'n groep lêers saam te stoor. Git stoor inhoud op 'n manier soortgelyk aan 'n UNIX-lêerstelsel, maar 'n bietjie vereenvoudig. Al die inhoud word as boom- en blob-objekte gestoor, met bome wat ooreenstem met UNIX-gidsinskrywings en blobs wat min of meer ooreenstem met inodes of lêerinhoud. 'n Enkele boomobjek bevat een of meer inskrywings, waarvan elkeen die SHA-1-huts van 'n blob of subboom is met sy geassosieerde modus, tipe en lêernaam. Sê byvoorbeeld jy het 'n projek waar die mees onlangse boom so lyk:

Die master^{tree} sintaksis spesifiseer die boomobjek waarna die laaste vaslegging op jou master-tak wys. Let op dat die lib-subgids nie 'n blob is nie, maar 'n wyser na 'n ander boom:

Konseptueel lyk die data wat Git stoor min of meer so:

Jy kan redelik maklik jou eie boom skep. Git skep normaalweg 'n boom deur die toestand van jou voorbereidingsarea (staging area) of indeks te neem en 'n reeks boomobjekte daaruit te skryf. So, om 'n boomobjek te skep, moet jy eers 'n indeks opstel deur 'n paar lêers voor te berei. Om 'n indeks met 'n enkele inskrywing te skep — die eerste weergawe van jou test.txt-lêer — kan jy die loodgietersopdrag git update-index gebruik. Jy gebruik hierdie opdrag om die vroeëre weergawe van die test.txt-lêer kunsmatig by 'n nuwe voorbereidingsarea te voeg. Jy moet die --add opsie daaraan gee omdat die lêer nog nie in jou voorbereidingsarea bestaan nie (jy het nog nie eers 'n voorbereidingsarea opgestel nie) en --cacheinfo omdat die lêer wat jy byvoeg nie in jou gids is nie, maar in jou databasis. Dan spesifiseer jy die modus, SHA-1 en lêernaam:

In hierdie geval spesifiseer jy 'n modus van 100644, wat beteken dat dit 'n normale lêer is. Ander opsies is 100755, wat beteken dis 'n uitvoerbare lêer; en 120000, wat 'n simboliese skakel spesifiseer. Die modus is van normale UNIX-modusse afgeneem, maar is baie minder buigsaam — hierdie drie modusse is die enigste wat geldig is vir lêers (blobs) in Git (hoewel ander modusse vir gidse en submodules gebruik word).

Nou kan jy git write-tree gebruik om die voorbereidingsarea na 'n boomobjek uit te skryf. Geen -w opsie is nodig nie — deur hierdie opdrag te roep word 'n boomobjek outomaties geskep vanaf die toestand van die indeks as daardie boom nog nie bestaan nie:

Jy kan ook verifieer dat dit 'n boomobjek is deur dieselfde git cat-file opdrag te gebruik wat jy vroeër gesien het:

Jy sal nou 'n nuwe boom skep met die tweede weergawe van test.txt asook 'n nuwe lêer:

Jou voorbereidingsarea het nou die nuwe weergawe van test.txt sowel as die nuwe lêer new.txt. Skryf daardie boom uit (wat die toestand van die voorbereidingsarea of indeks in 'n boomobjek aanteken) en kyk hoe dit lyk:

Let op dat hierdie boom beide lêerinskrywings het en ook dat die test.txt SHA-1 die “version 2” SHA-1 van vroeër is (1f7a7a). Net vir die pret sal jy die eerste boom as 'n subgids by hierdie een voeg. Jy kan bome in jou voorbereidingsarea inlees deur git read-tree te roep. In hierdie geval kan jy 'n bestaande boom in jou voorbereidingsarea inlees as 'n subboom deur die --prefix opsie met hierdie opdrag te gebruik:

As jy 'n werkgids sou skep vanaf die nuwe boom wat jy pas geskryf het, sou jy die twee lêers op die boonste vlak van die werkgids kry en 'n subgids genaamd bak wat die eerste weergawe van die test.txt lêer bevat. Jy kan dink aan die data wat Git vir hierdie strukture bevat asof dit so lyk:

As jy al die bogenoemde gedoen het, het jy nou drie bome wat die verskillende momentopnames van jou projek verteenwoordig wat jy wil naspoor, maar die vroeëre probleem bly: jy moet al drie SHA-1-waardes onthou om die momentopnames te herroep. Jy het ook geen inligting oor wie die momentopnames gestoor het, wanneer dit gestoor is, of hoekom dit gestoor is nie. Dit is die basiese inligting wat die vasleggingsobjek vir jou stoor.

Om 'n vasleggingsobjek te skep, roep jy commit-tree en spesifiseer jy 'n enkele boom SHA-1 en watter vasleggingsobjekte, indien enige, dit direk voorafgegaan het. Begin met die eerste boom wat jy geskryf het:

Nou kan jy na jou nuwe vasleggingsobjek kyk met git cat-file:

Die formaat vir 'n vasleggingsobjek is eenvoudig: dit spesifiseer die boonste-vlak boom vir die momentopname van die projek op daardie punt; die ouer-vasleggings indien enige (die vasleggingsobjek wat hierbo beskryf is, het geen ouers nie); die outeur/vaslêer (committer)-inligting (wat jou user.name en user.email konfigurasie-instellings en 'n tydstempel gebruik); 'n leë reël, en dan die vasleggingsboodskap.

Vervolgens sal jy die ander twee vasleggingsobjekte skryf, wat elkeen verwys na die vaslegging wat direk daarvoor gekom het:

Elkeen van die drie vasleggingsobjekte wys na een van die drie momentopname-bome wat jy geskep het. Vreemd genoeg het jy nou 'n regte Git-geskiedenis wat jy kan bekyk met die git log-opdrag, as jy dit op die laaste vaslegging SHA-1 uitvoer:

Verbluffend. Jy het pas die laevlak-operasies gedoen om 'n Git-geskiedenis op te bou sonder om enige van die voorvlak-opdragte (front end commands) te gebruik. Dit is in wese wat Git doen wanneer jy die git add en git commit opdragte uitvoer — dit stoor blobs vir die lêers wat verander het, werk die indeks by, skryf bome uit en skryf vasleggingsobjekte wat na die boonste-vlak bome verwys en die vasleggings wat onmiddellik voor hulle gekom het. Hierdie drie hoof Git-objekte — die blob, die boom en die vaslegging — word aanvanklik as aparte lêers in jou .git/objects gids gestoor. Hier is al die objekte in die voorbeeldgids nou, met kommentaar oor wat hulle stoor:

As jy al die interne wysers volg, kry jy 'n objekgrafiek wat min of meer so lyk:

Ons het vroeër genoem dat daar 'n kopstuk (header) gestoor word saam met elke objek wat jy in jou Git-objekdatabasis vaslê. Kom ons neem 'n minuut om te kyk hoe Git sy objekte stoor. Jy sal sien hoe om 'n blob-objek te stoor — in hierdie geval die string “what is up, doc?” — interaktief in die Ruby-skriptaal.

Jy kan interaktiewe Ruby-modus met die irb-opdrag begin:

Git konstrueer eers 'n kopstuk wat begin deur die tipe objek te identifiseer — in hierdie geval 'n blob. Aan daardie eerste deel van die kopstuk voeg Git 'n spasie by gevolg deur die grootte in grepe (bytes) van die inhoud, en voeg 'n finale nul-greep (null byte) by:

Git aaneenskakel die kopstuk en die oorspronklike inhoud en bereken dan die SHA-1 kontrolesom van daardie nuwe inhoud. Jy kan die SHA-1 waarde van 'n string in Ruby bereken deur die SHA1 digest-biblioteek met die require-opdrag in te sluit en dan Digest::SHA1.hexdigest() met die string te roep:

Kom ons vergelyk dit met die afvoer van git hash-object. Hier gebruik ons echo -n om te voorkom dat 'n nuwe reël by die invoer gevoeg word.

Git pers die nuwe inhoud saam met zlib, wat jy in Ruby kan doen met die zlib-biblioteek. Eerstens moet jy die biblioteek insluit (require) en dan Zlib::Deflate.deflate() op die inhoud uitvoer:

Ten slotte sal jy jou zlib-saamgeperste inhoud na 'n objek op die skyf skryf. Jy sal die pad bepaal van die objek wat jy wil uitskryf (die eerste twee karakters van die SHA-1 waarde is die subgidsnaam, en die laaste 38 karakters is die lêernaam binne daardie gids). In Ruby kan jy die FileUtils.mkdir_p() funksie gebruik om die subgids te skep as dit nie bestaan nie. Maak dan die lêer oop met File.open() en skryf die voorheen zlib-saamgeperste inhoud uit na die lêer met 'n write()-roep op die resulterende lêerhandvatsel:

Kom ons gaan die inhoud van die objek na met behulp van git cat-file:

Dis dit – jy het 'n geldige Git blob-objek geskep.

Alle Git-objekte word op dieselfde manier gestoor, net met verskillende tipes – in plaas van die string 'blob', sal die kopstuk begin met 'commit' of 'tree'. Verder, hoewel die blob-inhoud byna enigiets kan wees, is die vaslegging- en boom-inhoud baie spesifiek geformateer.