8.2 Git на ниско ниво - Git обекти

Следващият тип обект в Git е tree, който решава проблема със записа на името на файла и също така позволява да запазвате група файлове заедно. Git пази съдържанието по маниер подобен на UNIX файлова система, но една идея по-опростено. Цялото съдържание се съхранява под формата на tree и blob обекти, като дърветата играят ролята на съответните UNIX директории и blob-обектите съответстват малко или много на inodes или файлово съдържание. Единичен tree обект съдържа един или повече tree елемента, всеки от които съдържа SHA-1 указател към blob или поддърво със съответните име на файл, режим и тип. Например, най-новото дърво в проект може да изглежда по такъв начин:

Синтаксисът master^{tree} указва tree обекта, към който сочи последния къмит в master клона. Забелязваме, че lib поддиректорията не е blob, а указател към друго дърво:

Концептуално, данните които Git запазва изглеждат така:

Можете сравнително лесно да създадете собствено дърво. Git нормално създава дърво вземайки статуса на индексната област и записвайки серия от tree обекти от нея. Така, за да създадете tree обект, първо трябва да инициализирате индекса с някакви файлове. За да създадете индекс с един елемент — първата версия на файла test.txt, може да използвате plumbing командата git update-index. Използвайки я, добавяте изкуствено най-ранната версия на файла към нова индексна област. Трябва да подадете аргумента --add, защото файлът все още не съществува в индекса (и дори самият индекс още не съществува) и също --cacheinfo, защото файлът, който добавяте не е в работната директория, а е в базата данни. След това подавате режима, SHA-1 стойността и името на файла:

В този случай указваме режим 100644, което ще рече, че това е обикновен файл. Другите опции са 100755 за изпълним файл и 120000, който указва символна връзка (symlink). Режимът се взема съобразно стандартните UNIX правила, но е много по-малко гъвкав — това са единствените три режима, които са валидни за файлове (blobs) в Git (въпреки че други режими се използват за директории и подмодули).

Сега може да използвате git write-tree за да запишете индексната област в tree обект. Не се изисква флаг -w — изпълнението на тази команда автоматично създава tree обект съобразно статуса на индекса, ако такова дърво вече не съществува:

Може да проверите, че това е tree обект със същата git cat-file команда от по-рано:

Сега ще създадем ново дърво с втората версия на test.txt файла и също така още един нов файл:

Сега индексът ни има новата версия на test.txt, както и новия файл new.txt. Записваме това дърво в tree обект и поглеждаме как изглежда:

Забелязваме, че сега това дърво съдържа и двата файла, и че SHA-1 стойността на test.txt вече е “version 2” от по-рано (1f7a7a). Само за идеята, ще добавим първото дърво като поддиректория в това. Може да прочитаме дървета от индекса с командата git read-tree. В този случай, може да прочетем дърво от индекса като поддърво с параметъра --prefix към командата:

Ако създадем работна директория от новозаписаното дърво, ще получим в нея двата файла в корена ѝ и поддиректория bak, в която е първата версия на файла test.txt. Може да пресъздадем данните, които Git пази за тези структури, така:

Ако сте изпълнили всички стъпки досега, разполагате с три дървета, които представят различните snapshot-и на проекта, който искате да следите. Но проблемът все още стои: трябва да помните всичките три SHA-1 стойности, за да извлечете съдържанието им. Също така, нямате никаква информация за това кой е съхранил тези snapshot-и, кога са записани или защо са записани. Това е информацията, която съхраняват къмит обектите.

За да създадем такъв обект, използваме командата commit-tree, която очаква като аргументи SHA-1 хеша на единично дърво и също така, кой къмит обект (ако има такъв) директно го предшества. Започваме с първото съхранено дърво:

Сега можем да разгледаме новия ни къмит обект с командата git cat-file:

Форматът е прост: той указва top-level дървото за snapshot-а на проекта в този момент; родителските къмити, ако съществуват такива (описаният отгоре обект няма никакви родители); author/committer информацията (ще се използват текущите конфигурационни настройки за user.name и user.email и timestamp); следва празен ред и накрая е къмит съобщението.

Следва да запишем другите два къмит обекта, всеки от които сочи към къмита дошъл директно преди него:

Всеки от трите къмит обекта сочи към едно от трите snapshot дървета, които създадохме. Сега вече имаме и реална Git история, която може да видим с git log, ако я пуснем за SHA-1 стойността на последния къмит:

Чудесно. Току що извършихме операции от ниско ниво за да си изградим Git история без да използваме нито една porcelain команда. По същество това прави Git, когато изпълните git add и git commit — записва blob обекти за променените файлове, обновява индекса, записва дървета и записва къмит обекти, които сочат към top-level дърветата и къмитите дошли непосредствено преди тях. Тези три основни Git обекта — blob, tree, и commit, първоначално се съхраняват като отделни файлове в директорията .git/objects. Ето всички обекти в примерната ни директория с коментар за това, което съхраняват:

Ако проследим всички вътрешни указатели, получаваме графика от този вид:

По-рано казахме, че с всеки обект, който къмитваме в базата данни се пази и по един хедър. Нека видим как Git съхранява обектите си. Ще видим как да съхраним blob обект, в този случай стринга “what is up, doc?” — интерактивно в Ruby scripting езика.

Може да стартирате интерактивния Ruby режим с irb командата:

Git първо конструира хедър, който започва с идентифициране на типа на обекта — в този случай blob. Към тази първа част от хедъра, Git добавя интервал последван от размера на съдържанието в байтове и финален null байт:

Git конкатенира хедъра и оригиналното съдържание, след което калкулира нова SHA-1 стойност на резултата. В Ruby, можете да калкулирате SHA-1 стойност на стринг като инклуднете SHA1 digest библиотеката с require команда и след това викайки метода Digest::SHA1.hexdigest() със стринга:

Нека сравним това с изхода от git hash-object. Тук използваме echo -n за да избегнем добавянето на нов ред към входа.

Git компресира новото съдържание със zlib, което може да направите в Ruby с библиотеката zlib. Първо инклудвате библиотеката и след това изпълнявате Zlib::Deflate.deflate() за съдържанието:

Последно, записате zlib-deflated съдържанието в обект на диска. Установявате пътя за обекта (първите два символа от SHA-1 стойността са името на поддиректорията, останалите 38 са името на файла в нея). В Ruby може да използвате функцията FileUtils.mkdir_p() за да създадете директорията, ако тя не съществува. След това, отворете файла с File.open() и запишете в него zlib-компресираното съдържание с write() повикване към получения файлов указател:

Нека проверим съдържанието на обекта с git cat-file:

Това е, вече създадохте валиден Git blob обект.

Всички Git обекти се записват по същия начин, само с различни типове — вместо със стринга blob, хедърът ще започва с commit или tree. Също така, въпреки че blob съдържанието може да е практически всякакво, то commit и tree съдържанията се форматират строго специфично.