巨大リポジトリの窒息を解く：Gitの深淵「パックファイル」を制する最適化の極致
Gitは天才的なデータ構造を持っているが、その「柔軟性」は巨大プロジェクトにおいて諸刃の剣となる。数万のコミット、数ギガのバイナリ、数千のブランチを抱えたリポジトリで `git status` が数秒かかるようになったら、それはリポジトリが「肥満」している証拠だ。
多くのエンジニアは `git gc` を唱えて満足する。だが、本気でCI/CDのパイプラインを秒単位で削り取りたいのなら、Gitの心臓部である「パックファイル（Packfiles）」と「参照管理」の挙動を、カーネルレベルで理解する必要がある。
今日は、Gitのパフォーマンスを物理限界まで引き上げるための、深層チューニングについて語ろう。
—
1. なぜリポジトリは「遅延」するのか？
Gitの基本単位は「ルーズオブジェクト（Loose Objects）」だ。しかし、これが増えすぎるとファイルシステムへのIOPS負荷が跳ね上がる。Gitはこれを防ぐために「パックファイル」という形式で圧縮・アーカイブする。
問題はここからだ。
- パックの断片化: 定期的な `git gc` を怠ると、パックファイルが乱立し、Delta Chain（デルタチェーン）が伸びきり、オブジェクト検索のたびに大量のランダムアクセスが発生する。
- 参照の氾濫: 数千のブランチやタグが `.git/refs/` 下に散らばると、OSのファイルオープン処理自体がボトルネックになる。
これらを「最適化」するために、我々は手動で制御を握る必要がある。
—
2. `git pack-refs` による参照の平坦化
`git gc` を待つ必要はない。大量のブランチが存在する場合、参照を一つのテキストファイル（`packed-refs`）に押し込むのが定石だ。
エキスパートのハック:
CIのビルド開始直前や、リポジトリクローンの直後に以下のコマンドを叩くことで、ファイルシステムへの負荷を劇的に低減できる。
–all: すべての参照をパックする
–prune: パックした後の古いルーズ参照を削除する
git pack-refs –all –prune
これをCIのRunner起動スクリプトに組み込むだけで、特に大規模リポジトリでは `git fetch` や `git checkout` の初期フェーズのレイテンシが改善される。
—
3. Delta Compression の限界チューニング
Gitの圧縮効率は「デルタ圧縮（Delta Compression）」にかかっている。古いオブジェクトと新しいオブジェクトの差分を格納するわけだが、この探索ウィンドウを調整することで、CPU使用率と圧縮率のトレードオフを制御できる。
`~/.gitconfig` ではなく、リポジトリ単位の `.git/config` に以下のセクションを刻み込め。
[pack]
# デルタチェーンの最大長（デフォルトは50）
# 巨大なソースコードベースでは100〜200に増やすと圧縮率が向上する
depth = 100
# デルタ圧縮の探索ウィンドウ（デフォルトは10）
# メモリに余裕があるなら50以上に設定する
window = 50
# メモリ使用量制限（巨大パック作成時のOOMを防ぐ）
windowMemory = 1g
注意: これを極端に大きくすると `git gc` や `git repack` の実行時間が数倍に跳ね上がる。サーバー側のリポジトリメンテナンス時のみ適用し、クライアント側には配布しないのが賢明だ。
—
4. 現場で震えるほど役立つ「最適化自動化スクリプト」
ただコマンドを打つだけではプロとは言えない。リポジトリの健康状態を監視し、最適なタイミングで再パックする自動化スクリプトをCI/CDのサイドカーとして常駐させよ。
!/bin/bash
現場用：リポジトリ肥満度チェック＆最適化スクリプト
ルーズオブジェクトが5000を超えたら警告、10000で再パック
LOOSE_COUNT=$(git count-objects | awk ‘{print $1}’)
if [ “$LOOSE_COUNT” -gt 5000 ]; then
echo “[!] Warning: Loose objects count is high ($LOOSE_COUNT). Optimizing…”
# メモリを食い過ぎないよう、プロセス優先度を下げて実行
# –aggressiveは強力だが破壊的になり得るため、状況を見て使用すること
nice -n 19 git repack -a -d –depth=50 –window=50
git pack-refs –all –prune
echo “[+] Optimization complete.”
fi
—
5. 伝説のエンジニアからの提言：Gitの「向こう側」へ
もしあなたが、これらの最適化を行ってもなお速度に不満があるのなら、それはGitの限界に達している。その場合は、以下のアプローチを検討すべきだ。
1. Partial Clone (`git clone –filter=blob:none`): すべての履歴をDLするのをやめろ。必要なオブジェクトだけをオンデマンドで取得する。
2. Sparse Checkout: 全ファイルではなく、必要なディレクトリだけをローカルに展開する。
3. Scalar (Microsoft開発): Gitのパフォーマンスを極限まで高めるために設計されたツールだ。巨大なリポジトリ（Windowsのソースなど）を扱うための最適化がプリセットされている。
結び
Gitは単なる道具ではない。内部構造を理解し、その挙動を制御できる者だけが、巨大なコードベースを「鈍重な足枷」から「高速なエンジン」へと変貌させることができる。
パックファイルの断片化を恐れるな。デルタ圧縮の限界を攻めろ。そして何より、自分の手でそのリポジトリの「呼吸」を整えるのだ。それが真のDevOpsエンジニアの流儀である。