Gitリポジトリの「肥大化」という病：LFSのその先にある、真の最適化戦略
Gitはソースコード管理の革命児だった。しかし、現代の開発現場、特にアセットや学習データ、巨大なアーティファクトを扱うプロジェクトにおいて、Gitの設計思想は「重力」のように我々に牙を剥く。
`Git LFS`を導入すれば解決する？ それは教科書的な回答に過ぎない。LFSはあくまでポインタを置換するだけの「一時しのぎ」であり、実態としてのオブジェクトデータベース（`.git/objects`）の肥大化と、LFSストレージコストの爆発を食い止めるには、より深いレイヤでの外科手術が必要だ。
本稿では、リポジトリが「死」を迎える前に講じるべき、伝説級の最適化ハックを伝授する。
—
1. `git filter-repo` による過去の「残骸」の徹底排除
リポジトリが重くなる最大の理由は、過去に誤ってコミットされた巨大なバイナリが、`.git`ディレクトリ内のパックファイルに永久保存されていることだ。`git filter-branch`などはもはや遺物。`git filter-repo`こそが、現在我々が手にすべき唯一無二のメスである。
なぜ `filter-repo` なのか？
Pythonベースのこのツールは、単なる履歴書き換えを超え、オブジェクトの断片化を最適化し、Gitの内部構造を再構築する。
10MB以上の巨大ファイルを履歴から完全に抹消し、gcをかける
–path-glob で特定のディレクトリを対象にするのがコツ
git filter-repo –path-glob ‘assets/large-data/’ –strip-blobs-bigger-than 10M
実行後、リモートへ強制プッシュ（チーム全員の再クローンが必要になる点に注意）
git push origin –force –all
git push origin –force –tags
極限のハック:
CI環境でこれを実行し、`git gc –aggressive –prune=now` を組み合わせて定期的にパックファイルを再構成するパイプラインを組め。CIノードのディスクI/Oがボトルネックになるなら、`tmpfs`上で実行することで劇的な高速化が可能だ。
—
2. サブモジュール vs LFS：アーキテクチャの棲み分け
Git LFSに全てを委ねてはいけない。LFSは「差分が発生する巨大なファイル」には強いが、「一度置いたら動かない巨大なバイナリ（ライブラリやデータセット）」にはサブモジュール（または外部ストレージ）が適している。
- LFSの適正: ゲームのテクスチャ、頻繁に更新されるモデルデータ。
- サブモジュールの適正: バージョン固定された依存関係、数GB単位のライブラリ。
エキスパートの提言:
サブモジュールをURLから直接指すのではなく、社内専用のアーティファクトリポジトリ（ArtifactoryやAWS S3等）を指すスクリプトをCIに仕込むべきだ。Git自体を「巨大バイナリの保管庫」として使うという設計思想そのものを疑え。
—
3. ストレージクォータの自動監視：APIを叩き倒す
GitHubのストレージクォータは、「気づいた時には手遅れ」というケースがほとんどだ。CLIとGitHub APIを駆使して、クォータを可視化し、閾値を超えそうになったら自動で通知またはリポジトリの「剪定」を促すボットを構築せよ。
クォータ監視スクリプト（Python/PyGithub）
import os
from github import Github
GitHub Enterprise / Orgのストレージ使用量をAPIで取得
def check_storage_usage(org_name, token):
g = Github(token)
org = g.get_organization(org_name)
# LFSストレージ使用状況を取得
usage = org.get_lfs_usage()
# 80%を超えたらSlackへアラートを投げる
if usage.percentage > 80:
notify_slack(f”警告: リポジトリ {org_name} のLFSストレージが危険領域です: {usage.percentage}%”)
cronで1日1回実行すれば、突発的なストレージコスト増を未然に防げる
—
4. パイプライン最適化：フェッチの戦略的制限
CI/CDにおける巨大リポジトリの最大の敵は「クローン時間」だ。`git clone`で過去の全履歴をダウンロードする時代は終わった。
- shallow cloneの徹底: `git clone –depth 1` は基本。
- sparse-checkoutの活用: リポジトリの一部だけをチェックアウトする仕組みをCIジョブに組み込む。
GitHub Actionsにおける最適化例
- name: Checkout
uses: actions/checkout@v4
with:
fetch-depth: 1 # 直近のコミットのみ
lfs: true
sparse-checkout: |
src/
!assets/unused-data/ # 不要な巨大ディレクトリを除外
—
結論：Gitを「ソースコード管理」に戻せ
我々エンジニアが陥る罠は、「Gitに何でも詰め込める」という錯覚にある。Gitは分散型ソースコード管理システムであって、巨大なバイナリのバックアップストレージではない。
1. 定期的な外科手術（filter-repo）で過去の贅肉を削ぎ落とせ。
2. アーキテクチャを分離し、Gitの守備範囲をコードに限定せよ。
3. 自動監視を実装し、開発者の意識からストレージコストの懸念を消し去れ。
リポジトリは、美しく、速く、そして軽量であるべきだ。Gitを掌握した者が、プロダクトの速度を掌握する。健闘を祈る。