Git の内部構造：オブジェクト・packfile・gc・bisect を実測

シリーズ：Git 講座 6/6（上級）。 毎日 Git を使っていて（第1〜5回）、.git の中に何があるのか、なぜリポジトリが重く巨大になるのか、何かを壊したコミットをどう見つけるのかを知りたい人向けです。オブジェクトのハッシュを手で計算し、git commit を使わずにコミットを作り、gc・大容量ファイル・bisect を実測します。

「動画ファイルはコミットするな」と言われたけれど数字で納得したい人、rebase でハッシュが変わる理由が腑に落ちない人、300 個のコミットのどれが計算を壊したのか探さなければならない人のための記事です。オブジェクトモデルを知ると、Git の不思議な挙動（rebase 後に ID が変わる、「消した」コミットが戻ってくる、クローンが巨大になる）が予測できる結果に変わります。ここに載せたのは公式ドキュメントの言い換えではなく、すべて実際に実行して測った結果です。

環境：Git 2.54.0（Apple Git-157）、macOS の shasum、テストデータの生成に Python 3.9.6（システム標準）、Apple Silicon Mac（M1 Pro）。作業用リポジトリでデモ用の名前と固定日時を使っているので、以下のハッシュは再現できます。

blob は「blob <サイズ>\0」＋中身

$ printf 'hello\n' > hello.txt
$ git hash-object hello.txt
ce013625030ba8dba906f756967f9e9ca394464a
$ printf 'blob 6\0hello\n' | shasum -a 1
ce013625030ba8dba906f756967f9e9ca394464a  -

秘密はこれだけです。オブジェクト ID は、短いヘッダー（blob、空白、バイト数、NUL バイト）に中身を続けたものの SHA-1 です。ファイル名は含まれません。git add すると、ハッシュを名前にしたファイルがディスクに現れます（先頭2桁がディレクトリ名）。

$ find .git/objects -type f
.git/objects/ce/013625030ba8dba906f756967f9e9ca394464a
$ git cat-file -t ce01362     ->  blob
$ git cat-file -s ce01362     ->  6
$ git cat-file -p ce01362     ->  hello

ディスク上のファイルは 21 バイトで、zlib で圧縮されています。Python で展開すると、ハッシュされたバイト列そのものが見えます。

$ python3 -c "import zlib;print(zlib.decompress(open('.git/objects/ce/013625030ba8dba906f756967f9e9ca394464a','rb').read()))"
b'blob 6\x00hello\n'

1文字変えれば、まったく別のオブジェクトになります（hello → v2 で 8c1384d…）。Git は「変更点」を保存しません。版ごとに丸ごと保存し、後で packfile が圧縮します。

ツリーとコミット：スナップショットの保存方法

src/copy.txt（中身は同じ hello）と src/main.py を追加してコミットし、オブジェクトを数えました。

.git/objects/3d/f2b26e…   tree  (src/)
.git/objects/68/b30a75…   tree  (ルート)
.git/objects/87/2bfebe…   commit
.git/objects/b9/17a726…   blob  (main.py)
.git/objects/ce/013625…   blob  (hello.txt と src/copy.txt の両方)

3ファイルなのにオブジェクトは5つ。hello を含む2ファイルが blob を1つ共有しているからです。中身を読みます。

$ git cat-file -p HEAD
tree 68b30a75a76fffa7bf25023339501ec8cd7104d5
author demo <demo@example.com> 1794445200 +0000
committer demo <demo@example.com> 1794445200 +0000

First commit
$ git cat-file -p HEAD^{tree}
100644 blob ce013625030ba8dba906f756967f9e9ca394464a    hello.txt
040000 tree 3df2b26ecb8bcdda43db72b3f32af69ffa7736b3    src
$ git cat-file -p HEAD:src
100644 blob ce013625030ba8dba906f756967f9e9ca394464a    copy.txt
100644 blob b917a726c93f902e43291d9009d6488385133b67    main.py

ツリーはディレクトリの一覧（モード、種類、ハッシュ、名前）、コミットは小さなテキスト（ルートツリー、親コミット、作者、コミッター、メッセージ）です。そしてコミットも blob と同じ方法でハッシュされます。

$ git cat-file commit HEAD > c.raw
$ printf 'commit %s\0' $(wc -c < c.raw | tr -d ' ') | cat - c.raw | shasum -a 1
872bfebe6661489bdb33dce1ebf41088eb94f21b  -
$ git rev-parse HEAD
872bfebe6661489bdb33dce1ebf41088eb94f21b

親のハッシュがコミットの本文に入っているので、どこか1つのコミットを変えると、それ以降のすべてのコミットのハッシュが変わります。rebase が「履歴を書き換える」理由（第4回）も、コミット ID がその裏の履歴全体を保証できる理由も、ここにあります。

plumbing コマンドだけでコミットを作る

git commit は3つの「plumbing（配管）」コマンドを包んだ便利コマンドです。

$ echo "v2" > hello.txt
$ git add hello.txt
$ git write-tree
9bc1402c06ef1cef8f6d0e539a5333f3797b22de
$ echo "Commit made by hand" | git commit-tree 9bc1402 -p HEAD
6b582d907ea233b6037ec127b2e4405c052d999b
$ git update-ref refs/heads/main 6b582d9
$ git log --oneline
6b582d9 Commit made by hand
872bfeb First commit
$ git status --short
                       <- 何も出ない：インデックスは新しいツリーと一致している

write-tree はインデックスからツリーオブジェクトを作り、commit-tree はツリーをコミットで包み、update-ref はブランチ名を動かします。ブランチの正体は、ハッシュが1行書かれたファイルにすぎません。オブジェクトをいじり始めると出会うエラー：

$ git cat-file -p 0000000
fatal: Not a valid object name 0000000

SHA-256 のリポジトリもあります（git init --object-format=sha256）。そこでは git hash-object が 2cf8d83d…ebb4 を出力し、printf 'blob 6\0hello\n' | shasum -a 256 と一致しました。仕組みは同じで、ハッシュが長いだけです。

loose オブジェクトと packfile：gc を実測

git add や git commit のたびに loose オブジェクト（1オブジェクト1ファイルの zlib）が書かれます。git gc はそれを packfile にまとめ、似たオブジェクトは互いの差分（delta）として保存します。効果を見るため、Python の random.seed(7) で「1,000 行の CSV（30,691 バイト）の1行だけを変えるコミット」を 1,000 個作りました。在庫と価格の一覧を毎日少しずつ更新するイメージです。git fast-import で取り込んだ後 git unpack-objects で loose に展開し、毎回同じ 3,000 個の loose オブジェクトから始めています。

## gc 前
count: 3000
size: 19.53 MiB
## gc 後
count: 0
in-pack: 3000
packs: 1
size-pack: 484.38 KiB

pack の中身を種類別に（git cat-file --batch-check='%(objectsize) %(objectsize:disk)'）：

git verify-pack -v によると 990 個が delta として保存され、チェーンの深さは最大 49 でした。30 MB の CSV の履歴が 210 KB の blob になっています。ツリーに注目してください。小さなオブジェクトは zlib の固定オーバーヘッドのせいで、圧縮すると逆に大きくなります。

普段は自分で gc を実行する必要はありません。loose オブジェクトが一定数を超えると、Git が多くのコマンドの後に gc --auto を走らせます。第4回でベンチマークを壊したのも、このバックグラウンドの自動実行でした。

大容量バイナリ：痛みを実測する

次はよく警告されるケースです。20 MiB のランダムなバイト列（版 v ごとに Python の random.seed(v) を使うので再現可能）を 10 版コミットしました。動画やゲームのアセットを書き出し直すたびにコミットする状況です。

## 10 コミット後の loose
count: 40
size: 201.51 MiB
## git gc（1回）：24.49 秒
size-pack: 200.07 MiB

gc で減ったのは 0.7% で、時間はテキスト履歴の 0.8〜0.9 秒に対して 24.49 秒。20,971,520 バイトの各版は pack の中で 20,977,930 バイトを占めます。ランダムな（またはすでに圧縮された）データは縮まず、有効な差分もないので、Git はすべての版を丸ごと永遠に保存し、クローンするたびに全部をダウンロードします。3通りの方法でクローンしました（ローカルの file:// 転送なのでネットワーク時間は含まない）。各3回：

実際のネットワークでは差がもっと広がります。完全クローンは浅いクローンの約 10 倍のバイト数を転送するからです。部分クローンにも代償があります。浅いクローンでは git switch --detach HEAD~5 が fatal: invalid reference: HEAD~5 で失敗し（その履歴がない）、blobless クローンでは同じコマンドが成功する代わりに足りない版をその場で取得しました（ここでは 0.43 秒、.git は 20 MB から 40 MB に増加）。どうしてもバージョン管理が必要な大きなファイルには、Git にはポインタだけを置く Git LFS がありますが、このマシンには入っていないので試していません。

git bisect：300 コミットから 8 回で犯人を見つける

税込み計算が最初は正しく、今は間違っています。その間に「Refactor step N」という名前のコミットが 300 個。バグ（10% が 1% になった）はコミット 211 にありますが、知らないふりをします。bisect は履歴を二分探索し、git bisect run を使えば各コミットの判定をスクリプトに任せられます。スクリプトは正常なら 0、異常なら 1 で終了する必要があります。

#!/bin/sh
# test_tax.sh：0 = 正常、1 = 異常
out=$(python3 -c 'from tax import total; print(total(1000))')
[ "$out" = "1100" ]

$ git bisect start HEAD HEAD~299
Bisecting: 149 revisions left to test after this (roughly 7 steps)
[95892e7b…] Refactor step 150
$ git bisect run ~/demo/test_tax.sh
running '~/demo/test_tax.sh'
Bisecting: 74 revisions left to test after this (roughly 6 steps)
[d0546bdf…] Refactor step 225
running '~/demo/test_tax.sh'
Bisecting: 37 revisions left to test after this (roughly 5 steps)
[e787361d…] Refactor step 187
...
[72f52537…] Refactor step 211
running '~/demo/test_tax.sh'
72f52537d6519b73cf52dd4aa0392555090184c1 is the first bad commit
commit 72f52537d6519b73cf52dd4aa0392555090184c1
    Refactor step 211
 tax.py | 4 ++--
bisect found first bad commit
$ git bisect reset

古い順に全コミットをチェックアウトして最初に失敗するまでテストする素朴な方法と比べました。各3回（Apple Silicon Mac、M1 Pro）。

履歴が 10 倍になっても、bisect のテストは 3 回増えただけです。テストに1分かかる（ビルドとテストスイート）なら、11 分と1日半の差になります。

よくある失敗

壊れた bisect スクリプトが別のコミットを犯人にする。 テストスクリプトにタイプミス（pyhton3）を入れてみました。毎回 pyhton3: command not found が表示され、比較が失敗し、どのコミットでもスクリプトは 1（「異常」）で終了。bisect は自信満々にこう報告しました。

2d4b99385a37b3ebbb3cd09658e6d8af549f2ddd is the first bad commit
    Refactor step 2
bisect found first bad commit

対策：bisect run の前に、正常だとわかっているコミットでスクリプトを手動実行し、echo $? が 0 になることを確かめる。終了コード 125 は「テストできないのでスキップ」、127 を超えるコードは bisect を中断します。

start の前に git bisect good。 Git は You need to start by "git bisect start" と答えます。最後に git bisect reset も忘れずに。忘れると履歴の途中のコミットに detached のまま残ります。

.git/objects を ls -l してリポジトリの大きさを判断する。 見えるのは loose オブジェクトだけで、gc の後はほぼ空です。loose と pack を分けて表示する git count-objects -vH を使いましょう。

正直な限界・バージョンメモ

• 確認したのは Git 2.54.0（Apple Git-157）だけです。SHA-256 形式は Git 2.29 からあり、長く実験的扱いでした。SHA-1 と SHA-256 のリポジトリ間の相互運用は試していません。
• 部分クローン（--filter）はサーバー側の対応が必要です。今回のローカル「サーバー」は uploadpack.allowFilter=true にしています。ホスティングサービスによって異なります。
• gc の時間は CPU コア数（delta 探索はマルチスレッド）とディスクで変わり、実行ごとのばらつきは ±15% でした。大容量ファイルの gc は1回だけの計測です。
• du と count-objects の値は少しずれます（ファイルシステムのブロックとファイルのバイト数の違い）。表にはどちらを使ったか書いています。
• Git LFS と git filter-repo はこの環境に入っておらず、説明のみです。

練習問題

1. Git を使わずに、hi と改行だけ（3バイト）のファイルのオブジェクト ID を表示するコマンドラインを書いてください。その後 git hash-object で確かめましょう。
2. bisect のテストにはビルドが必要ですが、古いコミットでは依存関係が足りずに関係ない理由で失敗することがあります。その場合スクリプトは何で終了すべきで、なぜ 1 ではいけないのでしょう？

解答

1. printf 'blob 3\0hi\n' | shasum -a 1。printf 'hi\n' | git hash-object --stdin と一致するはずです（45b983be…）。
2. 125 で終了します。bisect に「このコミットはテストできないのでスキップ」と伝えるコードです。1 で終了するとそのコミットが異常と判定され、上の壊れたスクリプトと同じように探索が間違った場所へ進みます。

前回： Git 講座 5：reset・revert・reflog で元に戻す · シリーズの最初： Git 講座 1：init・add・commit · 関連：rebase と cherry-pick · 新人向け学習ロードマップに戻る