巨大リポジトリを外科手術せよ：git-filter-repoで歴史の呪縛を断ち切り、CI/CDを爆速化する
「`git clone` にコーヒーを淹れる時間が必要」
「CIのキャッシュサイズが制限を超えてビルドが止まる」
もしあなたのチームがこんな状況にあるなら、それはリポジトリが「負の遺産」を蓄積しすぎている証拠です。`.git`ディレクトリが数GBに達したリポジトリは、開発者の生産性を殺す最大の敵です。
今日は、`git filter-branch`という過去の遺物を捨て、伝説のツール `git-filter-repo` を使って、リポジトリを外科手術する極意を伝授します。
—
1. なぜ `git-filter-repo` なのか？
かつて主流だった `git filter-branch` は遅く、壊れやすく、そして何より歴史の書き換えにおいて「不完全」でした。`git-filter-repo` はその設計思想から異なります。Pythonベースで書かれ、Gitの内部構造を直接操作することで、圧倒的な処理速度と確実なリライトを実現します。
実務で使うべき理由
- 高速: 数十万コミットの履歴も数分で書き換える。
- 安全: 対象外のファイルやブランチを誤って破壊するリスクが低い。
- クリーン: `git gc` や `prune` を自動で最適化し、真の軽量化を達成する。
—
2. 現場で震えるほど役立つ：リポジトリ軽量化の全手順
手順A：過去の巨大バイナリを完全に消去する
`node_modules` や `build/` を誤ってコミットしてしまった場合、`git rm` だけでは歴史に残ります。以下のコマンドで「存在しなかったこと」にします。
対象の巨大ファイルを特定し、全履歴から消去
git filter-repo –path path/to/large-binary.zip –invert-paths
複数のディレクトリをまとめて削除したい場合
git filter-repo –path dir/to/delete1/ –path dir/to/delete2/ –invert-paths
手順B：特定ブランチだけ切り出して「脱・巨大モノリス」
マイクロサービス化を進める際、特定のディレクトリだけを新しいリポジトリとして切り出したいケース。これが一番の神機能です。
特定ディレクトリをルートに昇格させて切り出し
git filter-repo –path service-a/ –to-subdirectory-filter .
これにより、`service-a/` 以下の履歴だけを保持した新しいリポジトリが爆速で完成します。
—
3. 生産性を底上げする「神」ツールと設定術
ツールを知っているだけでなく、「体に覚えさせる」ことが重要です。
必須のGit神エイリアス
`.gitconfig` にこれを入れるだけで、日常の「Git疲れ」が激減します。
[alias]
# 最後に触ったブランチへの爆速移動
cm = checkout –
# 変更ログを美しく表示する（グラフ表示）
lg = log –graph –pretty=format:’%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset’ –abbrev-commit
# 巨大ファイルの検索（これを入れると犯人探しが速い）
find-big = “!git rev-list –objects –all | git cat-file –batch-check=’%(objectsize) %(objectname) %(rest)’ | sort -n | tail -n 10”
チーム開発の「設定ファイル共有」ベストプラクティス
チームで `.gitconfig` の一部を共有するには、`includeIf` を使います。
.gitconfig
[includeIf “gitdir:~/work/project-a/”]
path = ~/work/project-a/.gitconfig-local
これにより、案件ごとのコミットメールアドレスやフックの設定を自動で切り替えることが可能です。
—
4. CI/CDを極限まで速くする「Gitの心得」
リポジトリを軽量化した後、CIでさらに削り込むのがプロの流儀です。
1. 浅いクローン (Shallow Clone) を強制せよ:
CIのパイプラインでは、全履歴は不要です。`git fetch –depth=1` を活用し、転送量を最小化してください。GitHub Actionsなら `fetch-depth: 1` です。
2. Git LFSへの移行を検討せよ:
画像や動画など、どうしても消せないバイナリがあるなら、Git本体ではなく `Git LFS` に追い出してください。
3. 不要なリファレンスの削除:
`git-filter-repo` 後に `git reflog expire –expire=now –all` を叩くのを忘れないでください。これをしないと、ゴミデータが残ったままになります。
—
最後に：テックリードからの提言
「歴史を書き換える」ことは怖いかもしれません。しかし、肥大化したリポジトリは、チームの士気を削ぐ「負債」そのものです。
`git-filter-repo` を使ったリポジトリのメンテナンスは、定期的な健康診断です。年に一度は不要な歴史を捨て、クリーンな環境を保つ。それが、最高峰のエンジニアリングチームが常に高い生産性を維持するための、隠れた共通言語です。
さあ、今すぐあなたのリポジトリの `.git` サイズを確認してください。それが、明日からの開発スピードを左右する大きな一歩になります。