大規模開発の「負債」を「資産」に変える：Git LFSとサブモジュールの賢い付き合い方
こんにちは。大規模なプロジェクトの荒波を越えてきた皆さん、ようこそ。
開発規模が大きくなると、Gitは単なるソースコード管理ツール以上の存在になります。数GBのテクスチャ素材、数百のマイクロサービス、依存関係の迷宮……。これらを何も考えずにGitへ放り込むと、いずれ「`git clone`が終わらない」「リポジトリが重すぎてIDEがフリーズする」という地獄を見ることになります。
今回は、現場で生き残るための「Git LFS」と「サブモジュール」の極意を、初心者の方でも迷わないよう噛み砕いて解説します。これをマスターすれば、あなたのリポジトリは劇的に軽快になります。
—
1. 巨大なバイナリの救世主：Git LFS (Large File Storage)
なぜLFSが必要なのか？
Gitは本来、ソースコードのようなテキストファイルを管理するために設計されています。画像や動画、バイナリファイルを直接Gitに入れると、履歴が肥大化し、クローンするたびに過去の全バイナリをダウンロードする羽目になります。
Git LFSは、バイナリ本体を別のストレージに退避させ、Git内には「参照ポインタ（テキストファイル）」だけを置くことでこの問題を解決します。
セットアップの極意
まずは、自分のマシンにLFSをインストールしましょう。
LFSをインストール（初回のみ）
git lfs install
特定の拡張子（例: .psd, .mp4）をLFS管理下に置く
git lfs track “.psd”
git lfs track “.mp4”
.gitattributes が生成されるので、これを忘れずにコミットする
git add .gitattributes
git commit -m “LFSでバイナリ管理を開始”
【現場の知見】
`git lfs track` コマンドを打つ前に、`.gitattributes` ファイルの中身を確認してください。ここがLFSの「司令塔」です。ここを適切に管理しないと、チームメンバーがバイナリをコミットした際にLFS経由にならず、リポジトリが爆発します。必ずチームで共有しましょう。
—
2. 複数のリポジトリを繋ぐ：Git サブモジュール
サブモジュールとは？
「ライブラリや共通コンポーネントを独立したリポジトリとして管理し、メインのリポジトリから参照する」手法です。
メリット：
- 依存関係の明確化: どのバージョンの共通ライブラリを使っているか、Gitのコミットハッシュで厳密に固定できる。
- 独立した開発: 共通チームは共通リポジトリで作業し、アプリチームはその成果を「参照」するだけという分業が可能。
HelloWorld的な動作確認
まずは、既存のプロジェクトに外部リポジトリを組み込んでみましょう。
サブモジュールの追加
git submodule add https://github.com/example/common-lib.git libs/common
サブモジュールを含めたクローン（超重要！）
git clone –recursive <メインリポジトリのURL>
【現場の知見】
サブモジュールの最大の敵は「同期忘れ」です。
`git pull` をしてもサブモジュールの中身は自動で更新されません。チームメンバーには、クローン後に必ず `git submodule update –init –recursive` を叩く習慣を徹底させましょう。CI/CDパイプラインでも、このコマンドを組み込むのが鉄則です。
—
3. 現場で選ぶべき「現実的な選択基準」
これらをいつ使うべきか、迷ったら以下のフローを思い出してください。
1. 「そのファイルは頻繁に変わるか？」
- Yes → テキストならGit管理、バイナリならLFS。
- No → 外部ストレージ（S3やCDN）で配布し、GitにはURLだけを書く。
2. 「そのリポジトリは単体で完結するか？」
- Yes → モノレポ（1つの巨大リポジトリ）を検討してください。
- No（他チームと共有している） → サブモジュールの出番です。
最後のアドバイス：複雑さを恐れないこと
サブモジュールやLFSは「複雑そうだから避けたい」と思われがちです。しかし、何も考えずに巨大なリポジトリを運用する方が、将来的な「クローン時間の増大」や「ビルド環境の汚染」という遥かに大きなコストを支払うことになります。
最初は少し戸惑うかもしれませんが、一度仕組みを理解してしまえば、Gitはあなたの強力な味方になります。まずは小さなフォルダから、LFSとサブモジュールを試してみてください。
毎日の作業が劇的に軽くなる感覚、ぜひ体感してください。応援しています！