packfiles.asc

فایل‌های بسته (Packfiles)

اگر دستورالعمل‌های مثال بخش قبلی را دنبال کرده باشید، اکنون باید یک مخزن Git آزمایشی با ۱۱ شیء داشته باشید — چهار blob، سه tree، سه commit و یک tag:

$ 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 فشرده می‌کند و چون حجم زیادی ذخیره نکرده‌اید، مجموع این فایل‌ها تنها ۹۲۵ بایت را اشغال می‌کنند. حال می‌خواهیم محتوای بزرگ‌تری به مخزن اضافه کنیم تا یک ویژگی جالب Git را نشان دهیم. برای نشان دادن این موضوع، فایل repo.rb از کتابخانه Grit را اضافه می‌کنیم — این یک فایل کد منبع حدوداً ۲۲ کیلوبایتی است:

$ 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 محاسبه‌شده برای شیء blob جدید repo.rb خود را ببینید:

$ 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(+)

درختی که توسط آخرین commit ساخته شده را بررسی کنید، و نکتهٔ جالبی می‌بینید:

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

آن blob اکنون یک blob متفاوت است، که یعنی با اینکه شما تنها یک خط به انتهای یک فایل ۴۰۰ خطی اضافه کرده‌اید، Git محتوای جدید را به‌صورت کامل به عنوان یک شیء جدید ذخیره کرده است:

$ git cat-file -s b042a60ef7dff760008df33cee372b945b6e884e
22054

در دیسک خود دو شیء تقریباً یکسان ۲۲ کیلوبایتی دارید (هر کدام پس از فشرده‌سازی حدود ۷ کیلوبایت). خوب نبود اگر Git می‌توانست یکی از آن‌ها را کامل ذخیره کند و شیء دوم را فقط به صورت دلتا نسبت به اولی نگه دارد؟

مشخص می‌شود که چنین کاری ممکن است. فرمت اولیه‌ای که Git اشیا را روی دیسک ذخیره می‌کند، فرمت اشیاء “loose” نامیده می‌شود. با این حال، گاهی اوقات Git چند تا از این اشیاء را در یک فایل دودویی واحد به نام “packfile” جمع می‌کند تا فضای ذخیره را کاهش داده و کارایی را افزایش دهد. Git این کار را زمانی انجام می‌دهد که اشیاء loose زیادی داشته باشید، یا دستور git gc را دستی اجرا کنید، یا وقتی که به یک سرور راه دور push می‌کنید. برای دیدن آنچه اتفاق می‌افتد، می‌توانید از Git بخواهید اشیاء را بسته‌بندی کند با اجرای دستور git gc:

$ 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

اشیایی که باقی می‌مانند، بلاپ‌هایی هستند که هیچ کمیتی به آن‌ها اشاره نمی‌کند — در این مورد، نمونهٔ «`what is up, doc?`» و نمونهٔ «`test content`» که قبلاً ایجاد کرده بودید. چون آن‌ها را به هیچ کدام از کمیت‌ها اضافه نکرده‌اید، دورافتاده در نظر گرفته می‌شوند و در فایل پکی جدیدتان بسته‌بندی نشده‌اند.

فایل‌های دیگر، فایل پکی جدید و یک ایندکس هستند. پکی یک فایل واحد است که محتوای همهٔ اشیایی را که از سیستم فایل شما حذف شده‌اند در خود دارد. ایندکس فایلی است که افست‌ها (موقعیت‌ها) را داخل آن پکی نگه می‌دارد تا بتوانید سریعاً به یک شیٔ مشخص بپرید. نکتهٔ جالب این است که گرچه مجموع اندازهٔ اشیاء روی دیسک قبل از اجرای دستور gc حدود ۱۵ کیلوبایت بود، پکی جدید فقط ۷ کیلوبایت است. با بسته‌بندی اشیاء، مصرف دیسک‌تان را به نصف کاهش داده‌اید.

گیت این کار را چگونه انجام می‌دهد؟ وقتی گیت اشیاء را بسته‌بندی می‌کند، به دنبال فایل‌هایی می‌گردد که نام و اندازهٔ مشابهی دارند و تنها دلتاها (تفاوت‌ها) را از یک نسخهٔ فایل تا نسخهٔ بعدی ذخیره می‌کند. می‌توانید داخل پکی نگاه کنید و ببینید گیت برای صرفه‌جویی در فضا چه کاری انجام داده است. دستور plumbing یعنی 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

اینجا، بلاپ 033b4 که اگر یادتان باشد نسخهٔ اول فایل repo.rb شما بود، به بلاپ b042a اشاره می‌کند که نسخهٔ دوم همان فایل است. ستون سوم در خروجی، اندازهٔ شی در پکی را نشان می‌دهد، بنابراین می‌بینید b042a از فایل ۲۲ کیلوبایت را اشغال کرده، اما 033b4 تنها ۹ بایت حجم دارد. نکتهٔ جالب دیگر این است که نسخهٔ دوم فایل به‌صورت کامل ذخیره شده، در حالی که نسخهٔ اصلی به‌صورت دلتا نگهداری شده — چون به احتمال زیاد بیش‌تر به دسترسی سریع‌تر به جدیدترین نسخهٔ فایل نیاز خواهید داشت.

ویژگی واقعاً خوب این است که این پکی را در هر زمان می‌توان دوباره بسته‌بندی کرد. گیت گهگاه به صورت خودکار پایگاه‌دادهٔ شما را دوباره بسته‌بندی می‌کند و همیشه سعی می‌کند فضای بیش‌تری صرفه‌جویی کند، اما شما همچنین می‌توانید هر زمان که خواستید با اجرای دستی git gc دوباره بسته‌بندی کنید.