Git
Chapters ▾ 2nd Edition

8.4 Git на ниско ниво - Packfiles

Packfiles

Ако сте следвали инструкциите от предната секция сега трябва да имате Git хранилище с 11 обекта — 4 blob обекта, 3 tree обекта, 3 къмита, и 1 таг:

$ find .git/objects -type f
.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2
.git/objects/1a/410efbd13591db07496601ebc7a059dd55cfe9 # commit 3
.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a # test.txt v2
.git/objects/3c/4e9cd789d88d8d89c1073707c3585e41b0e614 # tree 3
.git/objects/83/baae61804e65cc73a7201a7252750c76066a30 # test.txt v1
.git/objects/95/85191f37f7b0fb9444f35a9bf50de191beadc2 # tag
.git/objects/ca/c0cab538b970a37ea1e769cbbde608743bc96d # commit 2
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 # 'test content'
.git/objects/d8/329fc1cc938780ffdd9f94e0d364e0ea74f579 # tree 1
.git/objects/fa/49b077972391ad58037050f2a75f74e3671e92 # new.txt
.git/objects/fd/f4fc3344e67ab068f836878b6c4951e3b15f3d # commit 1

Git ги компресира със zlib и резултатът не отнема много място, всички файлове заедно отнемат 925 байта. Сега ще добавим малко по-обемисто съдържание в хранилището, за да демонстрираме една интересна функционалност на Git. Добавяме файла repo.rb от библиотеката Grit — това е сорс код с размер около 22K:

$ curl https://raw.githubusercontent.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
$ git checkout master
$ git add repo.rb
$ git commit -m 'Create repo.rb'
[master 484a592] Create repo.rb
 3 files changed, 709 insertions(+), 2 deletions(-)
 delete mode 100644 bak/test.txt
 create mode 100644 repo.rb
 rewrite test.txt (100%)

Поглеждайки в полученото дърво, можем да видим SHA-1 стойността за новия repo.rb blob обект:

$ git cat-file -p master^{tree}
100644 blob fa49b077972391ad58037050f2a75f74e3671e92      new.txt
100644 blob 033b4468fa6b2a9547a70d88d1bbe8bf3f9ed0d5      repo.rb
100644 blob e3f094f522629ae358806b17daf78246c27c007b      test.txt

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

$ git cat-file -s 033b4468fa6b2a9547a70d88d1bbe8bf3f9ed0d5
22044

Променяме малко този файл и къмитваме:

$ echo '# testing' >> repo.rb
$ git commit -am 'Modify repo.rb a bit'
[master 2431da6] Modify repo.rb a bit
 1 file changed, 1 insertion(+)

Проверяваме дървото създадено от този последен къмит и виждаме нещо интересно:

$ git cat-file -p master^{tree}
100644 blob fa49b077972391ad58037050f2a75f74e3671e92      new.txt
100644 blob b042a60ef7dff760008df33cee372b945b6e884e      repo.rb
100644 blob e3f094f522629ae358806b17daf78246c27c007b      test.txt

Обектът blob сега е различен, което значи, че въпреки добавения само един ред в края на един файл от 400 реда, Git съхранява новото съдържание като изцяло нов обект:

$ git cat-file -s b042a60ef7dff760008df33cee372b945b6e884e
22054

Имаме два почти идентични 22K обекта на диска (всеки компресиран до около 7K). Дали няма да е по-добре, ако Git можеше да съхрани единия от тях изцяло, а другия само като разлика между двата?

Оказва се, че може. Първоначалният формат, в който Git записва обектите на диска се нарича “loose” формат. Обаче, в даден момент Git пакетира набор такива обекти в единичен binary файл известен като “packfile” с цел да спести място и да е по-ефективен. Git прави това, ако имате твърде много loose обекти, ако изпълните ръчно командата git gc или ако публикувате към отдалечен сървър. За да видите какво се случва, може да изпълните git gc за да накарете Git ръчно да пакетира обектите си:

$ git gc
Counting objects: 18, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (18/18), done.
Total 18 (delta 3), reused 0 (delta 0)

Ако сега погледнете в директорията objects, ще установите че повечето от обектите ви са изчезнали и се е появил чифт нови файлове:

$ find .git/objects -type f
.git/objects/bd/9dbf5aae1a3862dd1526723246b20206e5fc37
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
.git/objects/info/packs
.git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.idx
.git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.pack

Останалите тук обекти са blob обектите, към които не сочи нито един къмит — в нашия случай съдържанието от примерите “what is up, doc?” и “test content”. Понеже никога не са добавяни в къмит, те се третират като висящи и не се пакетират в новия packfile.

Останалите файлове са новия packfile и един индекс. Този packfile е единичен файл съхраняващ съдържанието на всички обекти, които са изтрити от файловата система. Индекс файлът съдържа отстъпите на обектите в packfile файла, така че лесно да търсите специфичен обект. Ценното в случая е фактът, че преди да изпълните gc командата, размерът на обектите беше около 15K, докато новият packfile е само 7K. Пакетирането съкрати наполовина използваното дисково пространство.

Как Git прави това? В процеса на пакетиране, Git търси файлове с подобни имена и размери и съхранява само разликите от една версия на файла към друга. Полученият packfile може да се изследва, за да видим какво точно е направено от Git. Командата git verify-pack позволява да видим какво е било пакетирано:

$ git verify-pack -v .git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.idx
2431da676938450a4d72e260db3bf7b0f587bbc1 commit 223 155 12
69bcdaff5328278ab1c0812ce0e07fa7d26a96d7 commit 214 152 167
80d02664cb23ed55b226516648c7ad5d0a3deb90 commit 214 145 319
43168a18b7613d1281e5560855a83eb8fde3d687 commit 213 146 464
092917823486a802e94d727c820a9024e14a1fc2 commit 214 146 610
702470739ce72005e2edff522fde85d52a65df9b commit 165 118 756
d368d0ac0678cbe6cce505be58126d3526706e54 tag    130 122 874
fe879577cb8cffcdf25441725141e310dd7d239b tree   136 136 996
d8329fc1cc938780ffdd9f94e0d364e0ea74f579 tree   36 46 1132
deef2e1b793907545e50a2ea2ddb5ba6c58c4506 tree   136 136 1178
d982c7cb2c2a972ee391a85da481fc1f9127a01d tree   6 17 1314 1 \
  deef2e1b793907545e50a2ea2ddb5ba6c58c4506
3c4e9cd789d88d8d89c1073707c3585e41b0e614 tree   8 19 1331 1 \
  deef2e1b793907545e50a2ea2ddb5ba6c58c4506
0155eb4229851634a0f03eb265b69f5a2d56f341 tree   71 76 1350
83baae61804e65cc73a7201a7252750c76066a30 blob   10 19 1426
fa49b077972391ad58037050f2a75f74e3671e92 blob   9 18 1445
b042a60ef7dff760008df33cee372b945b6e884e blob   22054 5799 1463
033b4468fa6b2a9547a70d88d1bbe8bf3f9ed0d5 blob   9 20 7262 1 \
  b042a60ef7dff760008df33cee372b945b6e884e
1f7a7a472abf3dd9643fd615f6da379c4acb3e3a blob   10 19 7282
non delta: 15 objects
chain length = 1: 3 objects
.git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.pack: ok

Тук blob обектът 033b4, който ако си спомняте беше първата версия на файла`repo.rb`, сочи към blob обекта b042a, който беше втората версия. Третата колона от изхода е размера на обекта в пакета. Така може да видите, че b042a заема 22K от файла, но 033b4 заема само 9 байта. Друг интересен факт е, че запазената изцяло версия на файла е втората такава, докато първата се пази само като разлика — това е защото се предполага, че най-вероятно ще се нуждаете от бърз достъп до най-актуалната му версия.

Наистина хубавото нещо във всичко това е, че по всяко време може да се направи ново пакетиране. Git от време на време автоматично препакетира базата данни като се опитва винаги да ви спести пространство. Но винаги можете да направите това и ръчно с командата git gc.

scroll-to-top