リポジトリ肥大化との決別：GitHub高速化のための「3種の神器」完全攻略ガイド
こんにちは。現場でコードを書き、パイプラインを磨き続けるエンジニアの皆さん。
開発が進むにつれ、「`git clone`が終わらない」「CIのビルド時間が異常に長い」といった悩みに直面していませんか？リポジトリの巨大化は、単なるストレージの浪費ではなく、チームの生産性とモチベーションを確実に削り取る「技術的負債」です。
今日は、GitHubという広大な海で迷子にならないための、「巨大化解決の3種の神器」を徹底解説します。これらをマスターすれば、毎日の作業が劇的に軽快になりますよ。
—
1. なぜリポジトリは「巨大化」するのか？
Gitは「全ての歴史を記録する」という性質上、以下の要素が溜まると爆発的に重くなります。
- バイナリファイルの混入: 画像、動画、学習済みモデルなど（Gitは差分管理が苦手）。
- 歴史の積み重ね: 数年分の不要なアセットが消されずに残っている。
- モノレポの弊害: 必要のないディレクトリまで全て手元にダウンロードしている。
これらを解決するための武器を順に見ていきましょう。
—
2. 【武器1】Git LFS (Large File Storage)
「バイナリファイルはGitの外へ逃がす」
Git LFSは、巨大なバイナリファイルをリポジトリ本体ではなく、専用のストレージに保存し、Gitには「ポインタ（参照情報）」だけを記録させる仕組みです。
導入と基本セットアップ
まずはインストールです。
macOSの場合（Homebrew）
brew install git-lfs
インストール確認と初期化
git lfs install
使い方の極意
特定の拡張子（例: `.psd`や`.zip`）をLFSの管理下に置きます。
.gitattributes ファイルに追跡対象を書き込む
git lfs track “.psd”
変更をコミット
git add .gitattributes
git commit -m “LFSでPSDファイルを追跡開始”
現場の知見: `git lfs track`を忘れると、うっかりバイナリをGitにコミットしてしまい、リポジトリが永久に汚染されます。必ず`.gitattributes`をチームで共有してください。
—
3. 【武器2】Git Submodules
「巨大なプロジェクトをコンポーネント単位で切り離す」
関連する別のリポジトリを、サブディレクトリとして取り込む手法です。巨大プロジェクトを「切り出せる」ため、影響範囲を限定できます。
基本的な使い方
サブモジュールの追加
git submodule add https://github.com/org/sub-project.git libs/sub-project
クローン時の注意（忘れがち！）
通常のcloneでは空っぽなので、必ず以下を実行
git clone –recursive
または後から取得
git submodule update –init –recursive
現場の知見: サブモジュールは強力ですが、運用が複雑になりがちです。「頻繁に更新されるモジュール」にだけ使い、単なるライブラリ管理ならパッケージマネージャー（npm, pipなど）を使う方が賢明です。
—
4. 【武器3】Sparse-Checkout
「必要なディレクトリだけを摘み取る」
これが今回の隠し玉です。「リポジトリは巨大だが、自分は特定のディレクトリしか触らない」という状況に最適です。
動作確認：必要なフォルダだけを取得する
1. 最小構成でクローン（履歴を深く取らない）
git clone –filter=blob:none –no-checkout
cd
2. sparse-checkoutを有効化し、特定のフォルダのみ指定
git sparse-checkout init –cone
git sparse-checkout set docs/architecture
3. ファイルをチェックアウト
git checkout main
これだけで、数GBあるリポジトリから、特定の数MBのフォルダだけが手元にやってきます。CI/CDパイプラインでのビルド時間を劇的に短縮する必須テクニックです。
—
5. まとめ：使い分けのロードマップ
状況に応じて、以下のように使い分けましょう。
| 手法 | 解決する問題 | 向いているケース |
| :— | :— | :— |
| Git LFS | バイナリ肥大化 | 画像・動画・モデルデータの管理 |
| Submodules | リポジトリの巨大化・依存分離 | 明確に分離可能なライブラリやツール |
| Sparse-checkout | 無駄なデータ取得 | モノレポで特定の機能のみ開発・CIする時 |
最後に：先輩からのアドバイス
「ツールを導入すること」が目的になってはいけません。最も大切なのは、「巨大なファイルをコミットしない」「不要な歴史を溜め込まない」というチームの規律です。
まずは、今のプロジェクトの `.git` フォルダのサイズを `du -sh .git` で確認してみてください。それが、改善の第一歩です。
皆さんの開発環境が、今日からもっと軽快で快適なものになりますように。応援しています！