Gitにおける大容量ファイルの未来はGitそのもの

• Gitプロジェクトは最近、公式に大容量ファイル管理の問題を直接解決し始めている
• Git LFSは、ユーザーにさまざまなコストやベンダーロックインなどをもたらす暫定策である
• 最近のpartial clone機能により、Git自体だけでLFSの役割の大半を代替できるようになった
• 今後はlarge object promisorという新しいソリューションも公式Gitへの統合が準備されている
• こうした変化により、大容量ファイル管理の究極的な解決策は外部拡張ではなくGitそのものへと収束していく見込みである

---

Gitの大容量ファイル問題と変化

• Git最大の宿敵（Nemesis）は、まさに大容量ファイルである
• 大容量ファイルはGitリポジトリを肥大化させ、git cloneの速度を低下させ、ほとんどのホスティング環境にも悪影響を与える

Git LFSの登場と限界

• 2015年、GitHubはGit LFSをリリースし、大容量ファイル問題を回避した
• しかしGit LFS自体が、新たな複雑さとストレージコストを追加した

• Gitコミュニティは静かに大容量ファイルの根本問題を考え続けてきたが、最近のGit公式リリースでは、LFSなしで大容量ファイルを管理する新たな方向性が示されている

今すぐ使える方法: Git LFSをpartial cloneで置き換える

• partial cloneの仕組み

  • Git LFS: 大容量ファイルをリポジトリ外に置き、必要なファイルだけをダウンロードして作業する仕組み
  • Git partial clone（2017年導入）:
    • --filterオプションで、指定したサイズ以上のblobを除外して複製する
    • 必要になったときだけ、その大容量ファイルをサーバーから取得する
      > Partial cloneを使うと、CloneやFetchの途中で[大容量バイナリアセット]を事前にダウンロードする必要がなくなるため、ダウンロード時間とディスク使用量を削減できる
      > - Partial Clone Design Notes, git-scm.com

• partial cloneとLFSの共通点

  • 1. チェックアウト容量の最小化: 最新版だけを取得し、ファイル全体の履歴は省略する
  • 2. 高速な複製: 大容量ファイルの転送がないため、cloneが速い
  • 3. 高速なセットアップ: shallow cloneと違い、プロジェクト全体の履歴にアクセスできる

• partial cloneの活用例

  • 大容量PNGファイルの履歴が多いrepoでの、複製速度とディスク使用量の実例:
    • 通常のcloneでは約4分、1.3GBの容量を使用
    • partial cloneで100KBのblob制限を適用すると、6秒で複製でき、49MBを使用
    • 元と比べて複製速度は97%改善、チェックアウトサイズは96%縮小

• partial cloneの限界

  • フィルタリングしたデータが必要になった場合（例: git diff, git blame, git checkout）、Gitはサーバーにファイルを要求する
  • これはGit LFSと同じ特徴である
  • 実務では、バイナリファイルに対してblameを行うことはまれである

Git LFSの問題点

• 強いベンダーロックイン: GitHubの実装は独自サーバーしかサポートせず、課金と依存関係を生む
• コストの問題: 50GB保存時、GitHub LFSは年間40ドル、Amazon S3は13ドル
• 元に戻しにくい: いったんLFSへ移行すると、履歴を書き換えない限り元に戻せない
• 継続的な設定コスト: すべての共同作業者にLFSのインストールが必須で、未導入だとファイルの代わりにメタデータファイルが見えてしまう（混乱の原因になる）

今後の展望: Large Object Promisor

• 大容量ファイルはホスティングプラットフォーム（GitHub、GitLab）にとってもコスト上の問題を引き起こす
• Git LFSは大容量ファイルをCDNへオフロードすることで、サーバーコストを削減している

• Large Object Promisorとは

  • 今年初め、Gitはlarge object promisorという機能を公式にマージした
  • この機能はLFSに似た形でサーバー側のストレージ負荷を減らしつつ、ユーザー側の複雑さを大きく減らす
    > この取り組みは、サーバー側の作業、特にすでにバイナリ形式で圧縮されている大きなblobの処理を改善することを目的としている
    > Git LFSの代替となるソリューションである
    > – Large Object Promisors, git-scm.com

• 動作原理

  • 1. ユーザーが大容量ファイルをGitホストへpushする
  • 2. ホストがバックエンドのpromisorへ大容量ファイルのオフロードを行う
  • 3. clone時にGitホストがクライアントへpromisor情報を提供する
  • 4. クライアントは必要に応じて、そのpromisorから自動的に大容量ファイルを取得する

• 現在の導入状況と課題

  • 大容量promisorはまだ開発中であり、2025年3月に一部コードがGitへマージされた
  • GitLabなどで追加実装と未解決課題の議論が進んでいる
  • 広く普及するまでにはまだ時間が必要である
  • 当面は大容量ファイル保存でGit LFSへの依存は避けられない
  • promisorが普及すれば、GitHubでも100MBを超えるファイルのアップロードが可能になる見込みである

結論: Gitの大容量ファイルの未来はGit

• Gitプロジェクトは、あなたに代わって大容量ファイル問題を絶えず考え続けている
• 現時点では、依然としてGit LFSの利用が必要である
• しかしpartial cloneとlarge object promisorsが進化するにつれて、Git LFSは徐々に不要になり、近い将来、大容量ファイルをGitだけで容易に管理できる時代が到来するだろう
• 将来は、GitにMP3ライブラリを入れようという発想だけが、大容量活用を妨げる最後の障害になるだろう