8月16日、Tyler Cipriani氏 が「The future of large files in Git is Git」と題したブログ記事を公開し、注目を集めている。この記事では、Git が抱える大容量ファイル問題の最終的な解決策として期待される「Large Object Promisors」を中心に、その背景と現状、そして将来像について詳しく紹介されている。以下に、その内容を紹介する。
大容量ファイルがもたらす問題
Git にとって大容量ファイルは長年の課題である。ファイルはリポジトリを肥大化させ、git clone を遅くし、ホスティングサービスに負担を与える。2015年に GitHub が Git LFS を導入したが、これは一時的な解決策に過ぎず、ユーザーにベンダーロックインや追加コストを押し付ける仕組みでもあった。
Git LFS が抱える主な問題点は次の通りである。
- ベンダーロックインが強い — GitHub の実装に依存し、他の選択肢が制限される。
- コストが高い — 例えば GitHub 上で 50GB を保存すると年 $40 が必要だが、同じ容量を Amazon S3 に保存すると $13 で済む。
- 元に戻せない — LFS を導入した後、履歴を改変せずに撤退することは困難である。
- セットアップコストが続く — 全員が LFS をインストールしないと、正しいファイルのやり取りができない。
このように LFS は「Git の問題をユーザーに転嫁する仕組み」であると著者は指摘する。
部分クローンという暫定解
2017年に導入された partial clone（部分クローン） は、Git LFS に似た仕組みを Git 本体に持ち込み、大容量ファイルを「必要になるまで取得しない」方式を実現した。
git clone --filter='blobs:size=100k' <repo>
著者の検証では、25MB の PNG ファイルを多数含むリポジトリを通常の clone で取得すると 1.3GB の容量と 4 分近い時間がかかったが、部分クローンでは 49MB・6秒に短縮できた。
部分クローンは LFS と同様に高速で軽量な環境を提供するが、git blame や git diff のように除外データを参照する操作では都度サーバーアクセスが必要になるなど、制約も残る。
本命となる「Large Object Promisors」
真に注目すべきは Large Object Promisors である。これは 2025年3月に一部が Git 本体へマージされた新機能で、LFS と同等のサーバー側メリットを提供しながら、ユーザーに余計な負担を強いない仕組みを目指している。
This effort aims to especially improve things on the server side, and especially for large blobs that are already compressed in a binary format.
This effort aims to provide an alternative to Git LFS
– Large Object Promisors, git-scm.com（この取り組みは特にサーバー側を改善することを目的としており、とりわけ既にバイナリ形式で圧縮されている大きな blob に効果を発揮する。
また、この取り組みは Git LFS に代わる選択肢を提供することを目指している。）
「プロミサ」とは何か
Large Object Promisors は、大容量ファイルのみを保持する特別な Git リモートを指す。通常の Git リポジトリとは別に用意され、ユーザーが push した大きなファイルは Git ホストからこの「プロミサ（promisor）」に自動的に退避される。
将来的に想定されている動作は以下の通りである。
- 開発者が大容量ファイルを Git ホストに push する。
- Git ホストがそのファイルを「プロミサ」に格納する。
- クローン時に Git ホストは、クライアントに「このリポジトリの大容量ファイルはプロミサにある」と伝える。
- 開発者がクローンしたとき、通常のソースコードや小さいファイルは Git ホストから取得し、大容量ファイルは透過的にプロミサから取得される。
つまりユーザー側から見れば、「大きなファイルを含むリポジトリを普通に clone したのに、裏では Git が自動的に外部リモートから大容量データを引っ張ってきてくれる」という動作になる。これにより Git LFS のように追加ツールをインストールする必要はなくなる。
今後の展望
Large Object Promisors はまだ発展途上であり、GitLab の議論や未解決の課題も多い。しかし普及すれば、GitHub が現在制限している 100MB 超のファイル push を解禁する可能性もある。
Gitで大容量ファイルを扱うための、現在の現実的な選択肢は依然として Git LFS だが、近い将来、大容量ファイルを扱う未来は Git 本体に収斂していくと見なされる。つまり、原文のタイトル 「The future of large files in Git is Git（Gitにおける大容量ファイルの未来はGitである）」 という言葉の通り、外部拡張ではなく Git 自身が解決策となる時代が訪れるということである。
詳細はThe future of large files in Git is Gitを参照していただきたい。
