【実務・中級編】大規模開発現場でのGit:サブモジュールとGit LFSの使いどころ – バージョン管理・CI/CD活用バイブル

大規模開発の「負債」を「資産」へ:Git LFSとサブモジュールを極限まで使いこなす技術

大規模な開発現場において、Gitは時に牙を剥く。バイナリファイルの肥大化によるクローン時間の増大、依存関係の迷宮、そして終わりのないマージコンフリクト。これらを放置しているチームは、毎日数時間の「待ち時間」という名のコストをドブに捨てている。

今日は、小手先のテクニックではなく、現場の生産性を劇的に向上させるための「Gitインフラの最適解」を伝授する。

—

1. Git LFS:バイナリ汚染からリポジトリを守る防波堤

バイナリファイルを直接Gitで管理するな。これは鉄則だ。数ギガの履歴がリポジトリを腐らせ、チーム全員のクローン体験を破壊する。

導入の真髄

LFSは単なる「外部ストレージ」ではない。「ポインタファイルによる軽量化」を正しく運用するためのプロトコルだ。

  • 設定の最適化:

全てのバイナリをLFS対象にするな。`.psd`, `.unitypackage` など、頻繁に更新され、かつ巨大なものに限定せよ。

.gitattributes のベストプラクティス
拡張子だけでなく、特定のディレクトリ配下をまとめて指定する
.psd filter=lfs diff=lfs merge=lfs -text
.unitypackage filter=lfs diff=lfs merge=lfs -text
assets/models/ filter=lfs diff=lfs merge=lfs -text

現場で震えるハック:`lfs.fetchinclude`

全バイナリを落とす必要はない。特定のブランチや特定のディレクトリだけを同期するように設定し、クローン時間を数分から数秒へ短縮する。

必要なものだけフェッチする設定
git config –global lfs.fetchinclude “assets/models/character/”

—

2. サブモジュール:疎結合な開発の「諸刃の剣」

「サブモジュールは地獄を見る」という言説は半分正解だが、それは「運用のルール」が欠如しているからだ。複数のコンポーネントが独立して進化する大規模環境では、サブモジュールこそが正義である。

注意すべき運用ルール

1. 「ブランチ追従」は禁止: デフォルトの `master` 追従は事故の元。必ず「コミットハッシュ」で固定せよ。
2. `submodule update –init –recursive` の自動化: メンバーが叩き忘れるコマンドは、フックに組み込むか、エイリアスを強制せよ。

神エイリアス(`.gitconfig`への追加)

以下の設定は、現場のエンジニアを救う。

[alias]
# サブモジュールを確実に最新の状態にする神コマンド
supdate = submodule update –init –recursive –remote –merge
# サブモジュールを含めたステータス確認
ss = status –submodule=summary

—

3. 開発スピードを加速させる「環境共有」の極意

個人設定の差は、マージ時のトラブルを引き起こす。「設定はコードである」という原則を徹底しろ。

推奨プラグイン & ツール

  • [delta](https://github.com/dandavison/delta): `git diff` を劇的に見やすくする。これなしでコードレビューは不可能だ。
  • [git-fuzzy](https://github.com/bigH/git-fuzzy): fzfを用いたインタラクティブなGit操作。ブランチの切り替えやログ探索が爆速になる。

設定ファイルの共有ルール

`git config` を各個人に任せるな。`.gitconfig` に `[include]` を使い、チーム共有の設定ファイルを読み込ませるのだ。

プロジェクトルートの .gitconfig_team を作成し、共有する
[include]
path = .gitconfig_team

.gitconfig_team の中身
[core]
# 改行コードのトラブルを撲滅
autocrlf = input
# 差分表示を最適化
pager = delta
[pull]
# マージコミットを作らない(履歴を汚さない)
rebase = true

—

4. 伝説のテックリードが現場に求める「黄金律」

最後に、ツール以上に重要なマインドセットを共有する。

1. コミットの粒度: 「変更の最小単位」を意識せよ。サブモジュールの変更と、アプリ側のロジック変更を同一コミットに含めるのは論外だ。
2. Gitフックによる自動防衛: `.githooks` ディレクトリをリポジトリ内に作成し、`pre-commit` フックでLFSのトラッキング漏れや、不要なデバッグコードの混入を自動検知せよ。

!/bin/bash
.githooks/pre-commit の一部(LFS漏れ防止)
if git ls-files | grep -E “\.(psd|unitypackage)$” | xargs git check-attr filter | grep -v “lfs”; then
echo “Error: バイナリファイルがLFSで管理されていません!”
exit 1
fi

まとめ

Git LFSとサブモジュールは、「管理コストを払ってでも、開発の並列性を最大化する」ためのツールだ。これらを使いこなすことは、単なるGit操作の習得ではない。チームの「認知負荷」を下げ、エンジニアが本来向き合うべき「コードの品質」に集中させるための、エンジニアリングの根幹なのだ。

さあ、今すぐ設定を見直し、チームのクローン時間を計測してほしい。計測できないものは改善できない。君のチームのGitが、ただの履歴記録ツールから、最強の加速装置へと変わる日を期待している。

タイトルとURLをコピーしました