チャプター ▾ 第2版

10.4 Gitの内側 - パックファイル

パックファイル

前のセクションの例にあるすべての手順に従った場合、現在、11個のオブジェクト（4つのBLOB、3つのツリー、3つのコミット、1つのタグ）を持つテストGitリポジトリが作成されているはずです。

$ 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の興味深い機能を実証するために、さらに大きなコンテンツをリポジトリに追加します。実証のために、Gritライブラリのrepo.rbファイルを追加します。これは約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%)

結果のツリーを見ると、新しいrepo.rb BLOBオブジェクトに対して計算されたSHA-1値を確認できます。

$ 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は別のBLOBになりました。これは、400行のファイルの最後に1行だけ追加したにもかかわらず、Gitがその新しいコンテンツを完全に新しいオブジェクトとして保存したことを意味します。

$ git cat-file -s b042a60ef7dff760008df33cee372b945b6e884e
22054

ディスク上には、ほぼ同じ2つの22Kオブジェクト（それぞれ約7Kに圧縮）があります。Gitがそれらのうちの1つを完全に保存し、2番目のオブジェクトは最初のオブジェクトとの差分としてのみ保存できるとしたら、どれほど素晴らしいでしょうか？

実は可能です。Gitがディスクにオブジェクトを保存する最初の形式は「ルーズ」オブジェクト形式と呼ばれます。ただし、スペースを節約し、効率を高めるために、Gitは時々これらのオブジェクトのいくつかを「パックファイル」と呼ばれる単一のバイナリファイルにパックします。Gitは、ルーズオブジェクトが多すぎる場合、手動で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」の例のBLOBです。これらをどのコミットにも追加しなかったため、これらはぶら下がっていると見なされ、新しいパックファイルにはパックされません。

その他のファイルは、新しいパックファイルとインデックスです。パックファイルは、ファイルシステムから削除されたすべてのオブジェクトのコンテンツを含む単一のファイルです。インデックスは、そのパックファイルへのオフセットを含むファイルであり、特定のオブジェクトにすばやくシークできます。素晴らしいのは、gcコマンドを実行する前のディスク上のオブジェクトが合計で約15Kのサイズであったにもかかわらず、新しいパックファイルはわずか7Kであることです。オブジェクトをパックすることで、ディスク使用量を半分に削減しました。

Gitはどのようにこれを行うのでしょうか？ Gitがオブジェクトをパックするとき、名前とサイズが似ているファイルを探し、ファイルのバージョンから次のバージョンへの差分のみを保存します。パックファイルを調べて、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

ここで、033b4 BLOB（覚えていれば、これはrepo.rbファイルの最初のバージョンでした）は、b042a BLOB（ファイルの2番目のバージョンでした）を参照しています。出力の3番目の列はパック内のオブジェクトのサイズなので、b042aがファイルの22Kを占めているのに対し、033b4はわずか9バイトしか占めていないことがわかります。また興味深いのは、ファイルの2番目のバージョンがそのまま保存され、元のバージョンは差分として保存されることです。これは、ファイルの最新バージョンへのより高速なアクセスが必要になる可能性が最も高いためです。

これの本当に良い点は、いつでも再パックできることです。Gitは時々データベースを自動的に再パックし、常にスペースを節約しようとしますが、手動でgit gcを実行することでいつでも手動で再パックすることもできます。

scroll-to-top