バージョン管理の第二の到来

バージョン管理の第二の到来

Plastic SCMの最初のエンジェル投資家との契約を交わした2005年の初夏、まさにその週に、Linus TorvaldsがGitを発表しました。私は1年以上かけて投資家を説得し、新しいバージョン管理システムを構築しようとしていましたが、突然、Linuxの生みの親自身がそれを開発し始めたのです。その週、私は今後の道のりが予想以上に困難になることを悟りました。

20年間、そのような同じような興奮を感じることはありませんでした。数ヶ月前まで。

2025年12月頃に私たちが手動コーディングをやめた一方で、別の大きな動きがありました。それは、2005年以来最大のバージョン管理革命です。
同時に2つの大きな動きが起きています。エージェントによるコミットペースの劇的な増加への対応の必要性と、GitHubを置き換えたいという突然の衝動です。
私は、これらの2つの力と、ソフトウェア開発の新しい方法を適応させ、サポートするバージョン管理システムから近い将来に期待できることについて考察します。

公平な警告：私は決して中立ではありません。私は20年間、Plastic SCMでGitと競合しました。アクティビジョンに巨大なモノレポについて約2年間アドバイスし、Diversionのアドバイザーを務め、現在はOriginで、誰もが不可能だと思っていたよりも速くGitを動作させる仕事をしているので、この戦いをリングのあらゆる角から見てきました。

巨人の失墜

わずか2年前に、GitHubがすぐに無関係になるだろうと誰かが言ったとしても、誰も信じなかったでしょう。GitHubはリポジトリホスティングの分野で揺るぎないリーダーであり、開発者がバージョン管理について考える方法さえ形作っていました。競合として（後述）多くの時間を費やした私はそれを痛感しました。もし何かが、人々が「GitHubのやり方」と理解していることと異なれば、それはおそらく間違っていると見なされていました。
GitHubはリポジトリ数と人々の意識の両方で依然として巨大であり、ソフトウェア開発とコラボレーション全般におけるその影響は計り知れず、おそらく今後もそうであり続けるでしょう。
しかし、もしあなたが十分に長くこの業界にいるなら、かつてSourceForgeに誰もが賭けていた時代があり、わずか数年後にGitHubの台頭とともに、それがほとんど無関係になったことを覚えているかもしれません。
私たちは今、同じ移行期にいるのでしょうか？ GitHubは何年にもわたって多くの素晴らしいことを成し遂げてきたので、それが存続することを願っていますが、明らかに大きな変動が起きています。

バージョン管理における私の人生

これを読んでいるということは、おそらく私が2005年にGitではないバージョン管理システムであるPlastic SCMを共同設立したことをご存知でしょう。それはパフォーマンスと巨大なリポジトリに焦点を当てたもので、2020年にUnityに買収されました。
しかし、私が最初に使ったバージョン管理システムは、2000年に大学卒業後の最初の公式な仕事で、Visual Source Safeでした。VSSとして知られるこのシステムは、これまで最も非難されてきたバージョン管理システムの一つでしたが、振り返ってみると、非常にシンプルで、プロジェクト間でファイルを共有しやすいという、おそらくまだ解決されていない良い点もいくつかありました。
数ヶ月後、IBMに買収されたClearcaseに触れる機会がありました。ベルギーのソニーに入社し、デジタルテレビを開発していた時です。最初はショックを受けましたが、Clearcaseは私の度肝を抜きました。信じられないほど優れたブランチングとマージ機能、仮想ファイルシステム、そして非常に柔軟でした。私は主にSunワークステーションからそれを使用し、幸いにもその「簡略化された」バージョンには当時触れませんでした（それはその力のほとんどを削ぎ落としたため、私見ではそれを殺す一因となったと思います）。
Clearcaseは非常に高価でした。私の記憶では、エンタープライズ設定でユーザーあたり年間約5,000ドルだったと思います。
バージョン管理のバグは私を深く捉えました。Clearcaseほど強力でありながら、より手頃な価格で、中小企業でも使えるようなものがあれば素晴らしいのではないか？ それからSubversionやCVS、さらにはPerforce（多くの大規模ゲーム開発チームやチップメーカーにとって、今でも最高のソリューションです）についても学びました。
私たちは、1年以上かけて潜在的な投資家にピッチするためのビジネスプランを作成した後、2005年の夏にPlastic SCMを開始しました。
その後、多くのバージョン管理システムが登場し、消えていくのを見ました。Accurevは、私たちが何度も競合した素晴らしいソリューションでしたが、今ではほとんど姿を消しています。MicrosoftのTeam Foundation Server、IBMのJazz（Clearcaseの後継を目指した）、Serena、そしてもう聞くことが難しくなった他の多くのシステムです。

2005年は最後の大きな爆発だった

2005年頃、Linuxカーネルのバージョン管理を勝ち取るための競争がありました。Bitkeeperは置き換えられる必要があり（それはそれ自体で語るべき物語です）、Mercurial、Darcs、そしていくつかの他のシステムがその王冠を狙っていました。正直なところ、Plastic SCMを立ち上げようとしていた私の夢も、Linuxカーネルをバージョン管理することでした。私の頭の中ではそれは素晴らしいように見えましたが、商用製品がそれに考慮されることさえ遠く及ばないだろうとは知りませんでした。しかし、おそらく、新しいバージョン管理システムを始めるのは、あまりにもナイーブだからでしょう。
そしてGitがレースに参入しました。あの夏私を動揺させたのと同じ発表で、そしてそれを勝ち取りました。それは革命であり、少し後、2008年頃にGitHubがそれを大衆に届け、あとは歴史となりました。
その時期に登場した新しいシステムを見るのは信じられないことでした。GitとMercurialはおそらく最も広く採用された2つでしょう。

第二の爆発

2025年末までに、私はいくつかの異なるチームと新しいバージョン管理ソリューションを開発している人々と話す幸運に恵まれました。そのうちのいくつかは以前から接触があり、いくつかは新しかったのですが、私が感じ始めたのは、明らかに何かが起こっているということでした。
誰もGitHubの優位性に挑戦することを敢えてしませんでしたが、今やあちこちのスタートアップが「次のGitHub」を作ろうとしていました。
私は確かに非常に重要なイニシアチブをいくつか忘れるでしょうが、私が最も興奮した主要なものを以下に挙げます。

Entire

GitHubの元CEOであるThomas Dohmkeが、Gitをベースにした新しいバージョン管理システムソリューションである彼の新しいベンチャーのために、巨額のシードラウンドを発表したとき、誰もが衝撃を受けました。
彼らは、どのエージェントがどのプロンプトでコードを作成したかを基本的に知ることができるprovenance tracking（来歴追跡）をリリースしました。これは、バージョン管理をどのように扱うかにおいて必須になると信じています。また、世界中の分散レプリカによる超高速クローンなど、多くのパフォーマンス改善も行っています。

Pierre

彼らのウェブサイトを訪れることは、それ自体が体験です（これがどれだけ続くかはわかりませんが）、それは他の何とも大きく異なります。Pierreは、より優れた差分とより優れたツリーをリリースしました。オープンソースなので、誰もがコードUIを強化できますが、その後、エージェント的な現実のためのGitフォージであるcode.storageに焦点を当てました。
GitHubは、コミット、PR、および一般的なトラフィックの信じられないほど高い増加に対処する際に、パフォーマンスの壁にぶつかりました。code.storageは、AIスケールで、基盤となるリポジトリを使用するすべてのプラットフォームのソリューションとして位置づけられています。
最近のXでの投稿で、Lovableやその他の大規模なAIソリューションがリポジトリを処理するために彼らのシステムに依存していることを明らかにしました。
これは間違いなく、そこにある最も有望なGitベースのソリューションの1つです。

Origin

私が聞いた最後のものですが、それを聞いたときに、業界で本当に大きなことが起こっていると実感しました。Cursor（現SpaceXAI）も独自のGitフォージに取り組んでいるのですか？素晴らしいです。
Originもまた、プルリクエスト、リポジトリホスティングなどの完全なソリューションを備えたフルGitフォージであり、これまでのところパフォーマンスと信頼性に焦点を当てていますが、他のすべてのGitプラットフォームと同様に、これはエキサイティングな旅の始まりにすぎません。
私の友人であり同僚であるVmgは、Originの内部構造に関する信じられないほどの記事（https://cursor.com/blog/git-at-any-scale）を投稿しました。これはXで数週間にわたって「WAL S3」の議論を引き起こしました。Scott ChaconやTobias Lütkeのような人々は、Vmgの記事に触発されて、数日後に独自のバージョンを実装しました。
これは私が数ヶ月前に参加したチームであり、前述したように、バージョン管理の内部構造に再びフルタイムで取り組んでいます。したがって、私の熱意をそれに応じて判断してください。今回は、Gitと競合するのではなく、可能な限り速くすることを目指しています。

GitButler

Scott Chaconの新しいバージョン管理ベンチャーはすでに数年前に存在していましたが、現在は「エージェントのためのバージョン管理」として位置づけられています。これは、異なるアプローチを取りながらも、同じトレンドをさらに発展させています。
これまでのところ、GitButlerは新しいフォージではなく、クライアントサイドに焦点を当てており、根本的に異なるユーザーエクスペリエンスの概念とパフォーマンスに重点を置いています。
スタックされたブランチ（私の意見では誰もが必要としています）、より良いリベース、そして私が言及したように、彼らが探求した「仮想ブランチ」のような革新的なアイデアは、Gitの進化の最先端に位置づけています。

East River Source Control - https://ersc.io

私のリストの中で、Gitの周りに何かを作成しているわけではない最初のグループです…しかしJujutsuの周りです。
私はGoogleのバージョン管理チームと数回話す機会がありました（そして、特に私が愛する超巨大モノレポに関して、彼らは非常にレベルが高いので、会話のすべての瞬間を楽しみました）。彼らは私をこのチームに紹介してくれました。このチームはJujutsuを市場に投入しています。
Jujutsuは、Martin von Zweigbergk（彼とも連絡を取る特権があります）によってGoogleでGitの後継として開始されました。スタックされたブランチのような革新的なアイデアをもたらし、リポジトリ内の未解決の競合さえバージョン管理することを超えており、これまでに不可能だった新しい機会を開きます。
コミットの並べ替え、変更の再適用（純粋なスタッキング）は、まったく異なる体験になります。
JujutsuはGit上で動作できますが、Google内部では異なるバックエンドを使用しており、erscは市場にそのアイデアをもたらそうとしています。GitHubにプッシュするとJujutsuの追加機能の一部が失われますが、ネイティブバックエンドがあればそれが変わるでしょう。
私はJujutsuの領域から多くの進化を期待しています。ネイティブなのか、Gitや他のバージョン管理システムに移植されるのかはわかりません。

Diversion

私は3年以上アドバイザーとしてDiversionと協力してきました。彼らは数年前から存在しており、これもGitベースではありません。当初、彼らは私のPlastic SCMでの古い日々を思い出させました。まったく異なるスタックでGitと戦っていました。
しかし、彼らのアプローチはかなり異なっており、これが彼らを「バージョン管理革命」において非常に重要にしている理由だと思います。彼らはポスト分散化された世界で生まれています。私はリモートリポジトリにプッシュ/プルすることに魅了されていました。実際、Plasticのバージョン2または3（2008年頃）では、それを「分散化」したので、Plasticは完全に集中型（SVNスタイル）と完全に分散型で動作でき、必要に応じて同じリポジトリで両方のモードを組み合わせることができました。私はこの柔軟性に魅了されていました。
しかし、分散化は、驚くべきものであると同時に、異なる世界で生まれました。今では飛行機に乗っているときでも、常にまともなインターネット接続があります。ローカルでコミットしてからプッシュする意味は何でしょうか？
私はDiversionのように大規模なリポジトリに焦点を当て、それがゲーム開発者にとって重要な差別化要因であることを発見しました。ゲーム開発チームは1TBを超えるリポジトリを、数百万のファイルで扱います。そのサイズでは、ローカルクローンを持つことは単に不可能です。
さらに、「コミットしてからプッシュする」という事実は多くのプロフェッショナルな環境で負担となっていたため、多くの人々は単に中央にコミットしたいだけでした。
これはDiversionが得意とするところですが、それは「Subversionの時代に戻る」とは見なせません。なぜなら、それははるかに優れたパフォーマンス、完全なクラウドデプロイメント、優れたブランチングとマージ（Gitで本当に洗練された部分）などを備えているからです。
Diversionは、サーバーサイドで完全にバージョン管理されたクラウドファーストワークスペースを導入しており、新しいコラボレーション方法を開拓しています。そして、それは異なりますが、Jujutsuができることの多くを思い出させます。

Oxen.ai

彼らのサイトで、AIの大規模データセットのバージョン管理を行っていることを現在認識するのは少し難しいです。私が最初に彼らに連絡したのは、アクティビジョンでバージョン管理（もちろん）をしていた時でした。なぜなら、彼らが巨大なデータセットを処理できるなら、ゲームシナリオも問題にならないはずだからです。
私は創業者たちと直接会う機会があり、チームと彼らの馴染みのあるアーキテクチャを本当に気に入りました。それは私に響きました（システムを高速にするための多くの超高速低レベル操作）。
Oxenは他のものと同じフォージレースには参加していませんが、市場が過去20年間で最も進化しているという事実の良い例です。

Lore!

興奮をさらに高めるために、Epic Gamesさえも、大規模モノレポ/ゲーム業界に目を向けたオープンソースバージョン管理システム、Loreをリリースしました。これはGitベースではない完全なフルスタックであり、非常に異なってエキサイティングです。Gitのような基盤となるDAG（有向非巡回グラフ）を共有し、大きなバイナリを処理するための改善、変更された部分のみをパッチし不要なダウンロードを回避するための最新アルゴリズムに基づく最適化されたデータ転送…そして、それは私には中央集権的に見えますが、オフラインでも動作できるようです。

近未来に期待すること

Diversionをカバーした際にその一部を説明しましたが、チームが直面する課題の多くは、非常に高いペースでコミットを受け取る大規模なモノレポになるだろうと本当に思っています。
MicrosoftがOfficeチームにGitを導入しようとしたとき、彼らはまず仮想ファイルシステム（私が本当に好きなソリューションタイプです）を開発して、Gitの分散的な性質と戦いました。これは大規模リポジトリでは短所でした。ファイル数が数百万に達すると、Gitの通常のレイアウトは役に立ちません。彼らはvfsを廃止し、「git scalar」が誕生しました。これは今や、どこでも大きなリポジトリを助けています。

（超）大規模モノレポのためのソリューション

多くのGitフォージがこの方向に進化するかどうかはわかりませんが、毎秒大量の貢献を受け取る大規模モノレポは、間違いなく将来のバージョン管理の分野の一つとなるでしょう。
おそらく、進化したGitがこれをカバーするのを見るかもしれません（基盤が適応できない場合、今日のものとは異なります）、あるいはまったく異なるスタック（Diversion、Lore、Oxen？）かもしれません。

分散化の終焉

私の賭けは、プッシュ/プルを伴う分散型（単なるコミットではなく）はリポジトリサイズによって制限されるということです。そのため、ある閾値（おそらくリポジトリサイズが300GBを超え、ファイル数が100万を超える場合）を超えると、業界はGitベースではないバージョン管理システムに存在したソリューションを見る必要が出てくるでしょう。おそらく、カスタムGitフォークがこれに対処するのを見るでしょう（AIはこれをスムーズに行えます）、そしておそらく2〜3年後の「Git」は、業界が根本的に異なるパラダイムを採用する勇気がない限り、今日見ているものとは根本的に異なるものになるでしょう。

超高速コミット速度

現在、Gitフォージでメインにコミットするにはある程度のシリアライゼーションが必要なため、コミット速度には限界があります。Googleは何年も前に内部のPiperソリューションでこの障壁を破りました（そして、それはGoogle内部でJujutsuが通信するものでもあります。外部で使えるGitバックエンドの代わりに）。そして、このアイデアを見直すソリューションが登場すると思います。

仮想ファイルシステムがあらゆるところに

これは間違いなく予測というよりは夢です。なぜなら、オンデマンドでモノレポから必要なファイルを取得する完全な仮想ファイルシステムで作業し、実質ゼロコスト（コピーオンライト）で無制限のローカルリポジトリコピーを持つことを可能にし、ユーザビリティと全体的なエクスペリエンスを大幅に向上させるというアイデアが大好きだからです。私はこれを25年前にClearcase（私にとってバージョン管理のXerox PARC）で初めて見て、Plastic用にそのバージョンを開発しました。そして、業界の巨人や多くの大規模ゲーム開発者がそれを使用しているのを見てきました。
しかし、これが起こるにはいくつかの障壁があります。第一にmacOSです。これは高速な仮想ファイルシステムの開発を事実上不可能にしています（LinuxとWindowsで並外れたパフォーマンスの実験を行いましたが、macOSでは不可能です）。第二に、エージェントが基盤となる複雑さをあまりにも隠蔽してしまい、私たちがもはや気にしなくなるかもしれませんが…それでも速度とディスクサイズは重要でしょう。

20年間で最高の時期

2005年、ダースのバージョン管理システムがBitkeeperを置き換えるために戦い、その勝者が20年間ソフトウェア開発を支配しました。そのレースで、決定的な要因がソーシャルネットワークを上に載せたホスティングサイトになると予測した人はいませんでした。

今回誰が勝つかもわかりません。おそらくGitHubは、Microsoftが最終的に常にそうするように適応するでしょう。おそらく、上記のフォージのいずれかが、エージェントによって書かれたコードのデフォルトのホームになるでしょう。おそらく、勝者は製品というよりは、中央集権的なモノレポ、バージョン管理されたワークスペース、ファーストクラスの競合といったパラダイムでしょう。

私が知っているのは、凍結期が終わったということです。20年間、バージョン管理における興味深い質問は「Gitにどう対処するか？」でした。今は「その次は何か？」です。そして、この分野でキャリア全体を費やし、Gitと競合し、挑戦者を支援し、そして今やGit自体を誰もが不可能だと思っていたよりも速くすることに取り組んでいる私から言えることは、バージョン管理を構築するのにこれほど良い時期はなかったということです。

2年後にまた聞いてください。あるいは、2026年の状況からすると、2ヶ月後に聞いてください。