問題：重いファイルのせいでGitが「鈍足」になる時
500MBの動画ファイルをGitHubにプッシュしようとして、亀のような進捗バーを眺めたことはありませんか？さらに悪いことに、15分待った挙挙句にFile exceeds 100MB limitというエラーが返ってくる…。そんな経験をしているのは、あなただけではありません。
以前、2,000枚以上のRAW画像（約15GB）を扱うコンピュータビジョンのプロジェクトに参加したことがあります。当時はGit LFSを知らなかったため、何も考えずにリポジトリにすべてコミットしてしまいました。その結果、同僚がgit cloneするたびに、膨大なデータをダウンロードするために1時間以上も待たせることになってしまいました。実際、彼らが作業に必要なのは数行のコードだけだったのにもかかわらず、です。
本来、Gitはソースコード（テキストファイル）を管理するために設計されています。各バージョンの変更点（diff）を記録することで履歴を保存します。しかし、画像や動画、AIモデルのようなバイナリファイルの場合、Gitは効率的に「diff」を計算できません。10MBの画像の1ピクセルを修正しただけで、Gitはさらに10MBのコピーを保存します。これにより、.gitディレクトリはあっという間に肥大化してしまいます。
Git LFS (Large File Storage) は、この問題を解決するために誕生しました。重いファイルを、わずか数KBの「ポインタ（pointer）」ファイルに置き換えて管理します。
クイックスタート：5分でGit LFSを設定する
理屈はさておき、実際にやってみましょう。例えば、200MBのvideo_demo.mp4を管理する必要があるとします。
ステップ1：ツールのインストール
OSに応じて、以下のコマンドを使用します：
- macOS:
brew install git-lfs - Ubuntu/Debian:
sudo apt install git-lfs - Windows: 公式サイト
git-lfs.github.comからインストーラーをダウンロード。
ステップ2：LFSの有効化
git lfs installこのコマンドは、PCで一度だけ実行すればOKです。
ステップ3：管理するファイル形式を指定する
例えば、すべての .mp4 ファイルをLFSで管理したい場合：
git lfs track "*.mp4"すると、.gitattributes というファイルが生成されます。これは「門番」のような役割を果たし、Gitに対して「このmp4ファイルには手を出すな、LFSに任せろ」と伝えます。
ステップ4：コミットとプッシュ
git add .gitattributes
git add video_demo.mp4
git commit -m "LFSを使用してデモ動画を追加"
git push origin mainとても簡単です！動画ファイルは専用のストレージサーバーに送られました。リポジトリは非常に軽量な状態に保たれます。
動作の仕組み：なぜLFSは速いのか？
200MBのファイルを直接 .git ディレクトリに詰め込む代わりに、LFSは以下のような内容のポインタファイルのみを保存します：
version https://git-lfs.github.com/spec/v1
oid sha256:a7c2... (ファイル識別ハッシュコード)
size 209715200git checkout を実行すると、Git LFSはこのポインタを読み取り、実際のファイルをサーバーからダウンロードします。そのファイルが含まれるブランチに切り替えない限り、ローカルストレージを1バイトも消費しません。これが、大規模なプロジェクトでも高速にクローンを維持できる秘訣です。
実践的なアドバイス：すでに肥大化してしまったリポジトリを救う方法
最もよくある間違いは、すでに数GBに膨れ上がったリポジトリに対して、新しいファイルだけを track することです。これでは効果がありません。なぜなら、古いファイルが依然としてコミット履歴の中に残っているからです。Gitは、深い操作を行わない限り、古いデータを自動的に削除することはありません。
根本的にクリーンアップするには、migrate コマンドを使用します：
git lfs migrate import --include="*.zip,*.psd" --everything警告： このコマンドはコミット履歴をすべて書き換えます。構造の衝突を避けるためにチーム全員が最初から git clone し直す必要があるため、実行前に必ずチームに通知してください。
ローカルストレージの最適化
しばらく運用していると、ブランチの切り替えを高速化するためにLFSが古いバージョンを保持し続け、ローカルのディスクがいっぱいになることがあります。空き容量を確保するには、以下のコマンドを使います：
git lfs pruneこのコマンドは、ローカルキャッシュ内の古いLFSファイルを削除しますが、サーバー上のデータは安全に保たれます。古いバージョンが再度必要になったときは、Gitが自動的に再ダウンロードします。
コストと帯域幅に関する注意点
Git LFSは非常に強力ですが、クラウドプラットフォーム上では完全に無料というわけではありません：
- GitHub: ストレージ1GB、帯域幅1GB/月まで無料。制限を超えると、追加プランの購入が必要です（50GBで月額約5ドル〜）。
- Self-hosted: 自前のVPSで Gitea や GitLab を運用している場合は、サードパーティへの費用を気にせず、自由に容量を構成できます。
ゲーム・グラフィック制作チーム向けのヒント：File Locking（ファイルロック）
UnityやUnrealのプロジェクトでは、.psd や .fbx などのバイナリファイルはマージできません。二人のメンバーが同時に同じ画像ファイルを修正すると、必ず競合が発生します。解決策は、File Locking 機能を有効にすることです：
git lfs track "*.psd" --lockableデザイナーがファイルを修正する際、git lfs lock character.psd を実行します。他のメンバーにはファイルがロックされていることが通知され、上書きプッシュができなくなります。これにより、データの消失を非常に効果的に防ぐことができます。
最後に
リポジトリが数GBに膨れ上がってから対策を考えるのではなく、メディアファイルを扱うプロジェクトを開始した瞬間に .gitattributes を設定しましょう。これにより、チームのワークフローは格段にスムーズでプロフェッショナルなものになります。もしインストール過程でエラーが発生した場合は、コメント欄で教えてください。サポートします！
