大規模リポジトリの「Git遅延」を撲滅せよ：Gitパフォーマンスチューニングの極意
大規模なコードベース、数万ファイルのプロジェクト。`git status`を打ってからコーヒーを淹れに行く時間があるなら、あなたの開発環境は「病気」です。
Gitはデフォルト設定では、巨大なリポジトリの変更検知において非常に非効率な挙動をします。今回は、Gitの深淵を知る者だけが知る、「Gitを爆速化させるための設定」を網羅的に解説します。
—
1. なぜGitは「遅い」のか？（ボトルネックの正体）
Gitのパフォーマンスを殺している最大の要因は、「全ファイルのステータスをOSのファイルシステムに問い合わせる」というコストです。
Gitはコマンドが叩かれるたびに、作業ディレクトリ内の全ファイルのメタデータ（mtimeやinode）をスキャンし、インデックスと比較します。数万ファイルある場合、この「スキャン」だけで数秒消費されます。これを解決するのが、`core.preloadindex`と`fsmonitor`です。
必須設定：`core.preloadindex = true`
これは、インデックスの読み込みをバックグラウンドのスレッドで行う設定です。現代のマルチコアCPUを活かす基本中の基本です。
インデックス処理を並列化する
git config –global core.preloadindex true
—
2. 究極の高速化：`fsmonitor` の真価
`fsmonitor`は、OSが提供するファイルシステム監視機能（macOSのFSEvents、WindowsのReadDirectoryChangesWなど）をGitにフックさせる仕組みです。
これを入れると、Gitは「どこが変更されたか」をOSから直接教わるようになります。その結果、全ファイルのスキャンが不要になり、`git status`が瞬時に終わります。
実践：fsmonitorの有効化
Git 2.37以降、`core.fsmonitor`はネイティブ実装されており、別途ツールをインストールする必要はありません。
fsmonitorを有効化（推奨）
git config –global core.fsmonitor true
ベンチマーク（目安）
- 設定前（数万ファイルの巨大リポジトリ）： 3.5秒 〜 5.0秒
- 設定後： 0.1秒 〜 0.3秒
改善率：約95%以上。 体感速度は「クリックした瞬間に終わる」レベルに変わります。
—
3. 生産性を底上げする「神」設定と運用ルール
設定だけでは足りません。チーム全体の生産性を底上げするためのプラクティスを共有します。
Git設定の共有化：`.gitconfig` のベストプラクティス
個人の設定をローカルで完結させるのではなく、プロジェクトルートに `.gitconfig` を配置する運用を推奨します。
.gitconfig (プロジェクト専用設定として読み込ませる)
[core]
# ファイルシステム監視を強制
fsmonitor = true
# インデックスの並列処理
preloadindex = true
# ガベージコレクションを賢く
gc.auto = 256
# 改行コードの自動変換（トラブルの元なので個別に制御）
autocrlf = input
[status]
# サブモジュールの変更検知を省略（大規模プロジェクトでは必須）
submodulesummary = false
チーム開発における「絶対ルール」
1. `git gc` の定期実行： 手動でたまに `git gc –prune=now` を叩く習慣を。リポジトリが肥大化する前に掃除をしましょう。
2. `git worktree` の活用： ブランチを切り替えるたびに `npm install` や `build` をやり直すのは時間の浪費です。`git worktree` を使い、機能ごとにディレクトリを分けることで、コンパイル待ち時間をゼロにします。
—
4. プロの道具箱：生産性を高めるツールとプラグイン
必須の神プラグイン：`zsh-git-prompt` または `Starship`
シェルプロンプト上でGitの状態を確認できるのは基本ですが、「重いリポジトリでプロンプトが固まる」のは最悪です。`Starship`のようにRustで書かれた超高速なプロンプトエンジンを採用してください。
隠れたキーボードショートカット
`git status` を打つ回数を減らすのが真の最適化です。
- `git checkout -` : 前のブランチに戻る（日常的な頻出）。
- `git commit –amend –no-edit` : 直前のコミットに修正を含める（ミスした時に即座に叩く）。
- `git reflog` : 詰んだ時に命を救う最後の砦。これを知らないエンジニアはGitを扱っているとは言えません。
—
5. 最後に：テックリードからのアドバイス
「ツールを速くする」ことは、単なる自己満足ではありません。「思考のコンテキストスイッチを最小化する」ことが、エンジニアの創造性を最大化します。
`git status` が遅いだけで、脳は数秒間「待機」というタスクに切り替わります。この無駄な脳のコストを削り取り、コードのロジックを考えることにリソースを全振りしてください。
今日紹介した設定をチームに導入し、開発環境を「ストレスゼロ」の領域へ押し上げてください。健闘を祈ります。