バージョン管理システムの一覧

バージョン管理システムは、ファイルの変更の履歴を記録し、複数の人や機械の間で共有するソフトウェアである。2026年の時点で最も広く使われているのはGitで、その周りにGitのリポジトリをそのまま扱う互換のツールと、Gitの部品を別の言語で作り直した実装がある。ほかに、Gitとは別の形式を持つ分散型のシステムと、履歴の元をサーバーだけに置く集中型のシステムがある。

2026年には、コーディングエージェントが変更を出す量の急増を受けて、大規模なリポジトリの扱い方を作り直す動きが続いた。Anthropicは社内のモノレポをGitから独自のScionに移し¹、OpenAIはGitと互換のままサーバー側をPandoに作り替えた²。GitHubとCursorも、Gitのサーバーの書き込みの方式を変えたと公表している³⁴。

分類

この記事では、次のように分ける。

Saplingは、Gitのリポジトリを扱うクライアントと、独自形式のサーバーの両方を持つため、2つの分類にまたがる⁵。

歴史

初期のバージョン管理システムは、1つのファイルの版を手元で管理するRCSのようなものだった。その後、CVSとSubversionが、サーバーにリポジトリを置く集中型を広めた⁶。

2005年、Linuxカーネルの開発で使っていた商用のBitKeeperが無償で使えなくなった。これを受けて、リーナス・トーヴァルズがGitを、マット・マコールがMercurialを、同じ年に作り始めた⁷⁸。2008年にGitHubが始まってから、Gitは利用者を急速に増やした⁷。

Git

Gitは、リーナス・トーヴァルズが2005年に作った分散型のバージョン管理システムである。どのクローンも履歴の完全な写しを持ち、手元だけで差分・履歴・ブランチを扱える。GPLv2で公開されている⁷。2026年11月3日の時点で最新の安定版は2.56.0である⁹。

次の大きな版のGit 3.0では、新しいリポジトリの既定のハッシュをSHA-1からSHA-256に変え、参照の保存の形式をreftableに変える予定である。公式の文書は、3.0を出す日をまだ決めていないとしている¹⁰。

AI企業と開発基盤の動き

Scion（Anthropic）

ScionはAnthropicが作った社内のバージョン管理システムで、同社は2026年10月13日にエンジニアリングの記事でこれを公表した。7人のチームが、コードレビューの道具のAntiqueとともに作り、5か月でモノレポをGitから移した¹。

記事によると、同社のモノレポで1日にマージされる変更は、2026年5月の約2,500件から、9月には30,000件を超えた。mainブランチの履歴だけで100GB近くあり、CIのチェックアウトは1日に2,500万回ほどに上る。最も多い時期には、数百のGitのミラーを動かしていた¹。

Scionの設計は、Gitの分散型の前提を捨てている。クライアントは常にサーバーにつながっている前提で、履歴やblameの問い合わせ、コミットの作成、マージやリベースはサーバーが行う。クライアントは上限のあるオブジェクトのキャッシュだけを持つ¹。データの単位は「changeset」で、最初の親からの変更のあったファイルの一覧と、ブロブストレージ上の圧縮した中身への内容アドレスを持つ。Gitのpackfileに当たるものは無い。サーバーはSpannerとクラウドのストレージの上で動き、リポジトリの完全な写しはサーバーにも存在しない。チェックアウトはスパースか、ファイルを要るときだけ取り出す仮想化した形を基本とする¹。

記事は、ScionのCPUとメモリの使用量が以前のGitのミラーの200分の1になり、CIと研究のジョブのチェックアウトが分単位から秒単位に縮んだと述べている¹。マージキューについては、エージェントの規模ではリポジトリ全体のロックを取る従来の方式が成り立たないとし、マージ後とデプロイ前の自動テストに投資したと書いている¹。

先行例として、記事はGoogleのPiperとMetaのSaplingを挙げている。記事の注は、Saplingのサーバー側のMononokeがScionの使う手法の多くを先に実現しており、とくにBonsaiと呼ぶデータモデルがそうだと述べている¹。この注は、公表の2日後の10月15日に足された¹¹¹。

Anthropicは、Scionを「一般の用途でgitの代わりになるものでは決してない」としている。数万人の技術者か大量のエージェントがコードを書く巨大なモノレポでしか意味を持たない設計だとして、公開はせず、考え方をGitHub・GitLab・オープンソースのコミュニティと共有するとした¹。

Pando（OpenAI）

PandoはOpenAIが作った、Gitのリポジトリのための新しいサーバー側の実装である。同社は2026年11月2日に、アーロン・フリール、テイラー・ブラウ、テッド・ナイマンの署名の記事「Scaling Git at OpenAI」で公表した。Gitの通信の手順とクライアントの互換を保ったまま、同社のモノレポのすべての開発を支えている²。

記事によると、モノレポのmasterに入るコミットの数は、2024年第1四半期と比べて2026年第3四半期に1,378%増えた。2025年の末ごろからは取得とpushの遅れやマージの失敗が増え、信頼性が90%を下回ることもあった²。

Pandoは、リポジトリ全体で参照の状態をそろえることをやめ、参照ごとの更新だけを順に並べる。記事はこれを因果一貫性と呼んでいる。pushされたpackfileは不変のブロブとしてブロブストアに置き、参照が動くたびに、新しい先端・それを運んだpackfile・依存する以前のref versionを「ref version」としてメタデータのストアに記録する²。新しいブランチのpushに対しては、既定ではtrunkだけを知らせる。こうするとクライアントの作るpackfileはtrunkにだけ依存し、別の取得の応答にそのまま使い回せる²。

取得では、Gitのpackfile-uriの機能でpackfileの場所だけを返し、クライアントは地域ごとのキャッシュのExpressから取り出す。キャッシュの的中率は99%を超え、普通のクラウドの仮想マシンで10Gbpsの回線を使い切れたという²。pushのたびにできる小さなpackfileは、LSMツリーの圧縮に似た方式で段階的に大きな「cover」にまとめ、2026年11月の時点でL4まで使っている²。

PandoはRustで書かれ、着手から本番まで10週間で作られた。中核は1人の技術者が設計し、エージェントのチームが実装し、2026年4月から本番の通信を扱っている。記事は、GPT-6 Astraを使ってLeanとTLA+でPandoの性質を形式化し、実装の不具合を見つけたとも書いている²。最初は既存のソース管理の前に置く読み書きの代理として動かし、通信を少しずつ移した。既存のシステムの名前は書かれていない²。

記事は、中央値のpushの待ち時間が5分の1近くまで縮んだと述べている。1日に1ペタバイト近いGitのデータを少数のCPUコアで配り、1時間に57テラバイトを超えるpackを配った時もあるという²。

OpenAIは、自社でビルドしたGitを開発機とChatGPTのデスクトップアプリに配り、その修正をGitHubのopenai/gitで公開している。一部はすでに本家のGitに取り込まれた²。Pando自体のソースコードは公開されていない。記事は、Pandoを支える技術を利用者と共有する方法を探っているとしている²。

GitHubとCursor

GitHubは2026年10月、リポジトリをAzureに移す作業の記事で、Gitのサーバーの部品Spokesの書き込みを変えたと述べた。従来はすべての書き込みがリポジトリ全体のロックを取っていたが、同じ参照への書き込みだけを順に並べる方式に切り替え、社内の試験で書き込みの量が3〜4倍になったという³¹¹。

Cursorは2026年8月、Gitのホスティングの「Origin」のための保存の仕組みContinuityを公表した。Gitの形式はそのまま保ち、S3互換のストレージ上の先行書き込みログを唯一の確かな記録とし、各サーバーの手元のリポジトリはそこから作り直せるキャッシュとして扱う⁴。

ほかに、GitHubの元CEOのトーマス・ドームケらが共同で創業したEntireや、Enrouteも、エージェントのpushの量に合わせたGitのサーバーを公表している¹¹。

Oak

Oakは、ザック・ギアーが作る、人とエージェントが一緒に使うためのバージョン管理システムである。ベータの間は無料で、組織ごとに100GBの保存領域が付く¹²。ファイルを読んだときに取り出す遅延マウント、メッセージの要らないチェックポイント、大きなファイルの分割と重複の排除を持つ。oak exportで全履歴をGitのリポジトリに書き出せる¹²。公式サイトは、大きなバイナリを含む作業のスナップショットがGitより95%速いとしている。ただし、5万ファイルの初期化とプロセスの起動はGitのほうが速いとも書いている¹²。

Git互換のクライアント

Jujutsu

Jujutsu（コマンドはjj）は、マーティン・フォン・ツヴァイクベルクが2019年に個人の計画として始め、のちにGoogleでの仕事になったバージョン管理システムである。Rustで書かれ、Apache License 2.0で公開されている¹³。保存先にGitのリポジトリを使えるため、GitHubなどのGitのホスティングとそのまま併用できる¹³。

作業ディレクトリそのものをコミットとして扱うため、ステージングの段階が無い。すべての操作を操作ログに残し、どの操作も取り消せる。衝突はコミットの中にそのまま記録でき、解消を後に回せる。子孫のコミットは、親を書き換えると自動でリベースされる¹³。2026年10月7日に0.46.0が出ており、版はまだ1.0に達していない¹⁴。

Sapling

SaplingはMetaが社内で使い、2022年11月に公開したバージョン管理システムである。クライアントはMercurialから派生し、GitHubのGitのリポジトリを扱える。社内では、サーバーのMononokeと、ファイルを必要なときに取り出す仮想ファイルシステムのEdenFSと組み合わせて使う⁵。積み重ねたコミットを1つずつのプルリクエストにする機能や、スマートログと呼ぶ履歴の表示を持つ。ライセンスはGPLv2である⁵。版の番号に日付を入れて頻繁に出しており、2026年11月2日の日付のタグがある¹⁵。

GitButler

GitButlerは、GitHubの共同創業者で『Pro Git』の著者のスコット・シャコンらが作る、Gitの上に作ったクライアントである。同じ作業ディレクトリで複数のブランチを同時に扱う「仮想ブランチ」と、積み重ねたブランチを扱う機能を持つ。デスクトップアプリはTauriとRustとSvelteで書かれ、2026年2月の0.19.0でほとんどの操作をコマンドラインからも使えるようになった¹⁶¹⁷。2026年4月に1,700万ドルのシリーズAの資金を集めたと報じられている¹⁸。2026年11月3日の時点で最新の安定版のタグは0.23.2である¹⁷。

git-branchless

git-branchlessは、ワリード・カーンが作る、Gitに積み重ねたコミットの扱いを足す道具である。Gitの上で動き、コミットのグラフの表示や、操作の取り消し、子孫の自動のリベースを持つ。Rustで書かれている¹⁹。最新のタグは0.11.1である¹⁹。

Gitの実装

Gitの機能をほかのプログラムから使うために、Gitを別の言語で実装したライブラリがある。ホスティングのサービスや開発環境、CIの多くは、これらのどれかでリポジトリを読む。

gitoxideは、セバスチャン・ティールが始めた、GitをRustだけで実装する計画である。ライブラリのgixと、コマンドラインのgix・einからなり、MITとApache License 2.0の二重のライセンスで公開されている²⁶。0.61.0では、下位のクレートのエラーの型をRustの標準の形に合わせ、セキュリティの修正を入れた¹¹。

Gitとは別の形式の分散型

Mercurial

Mercurialは、マット・マコールが2005年に作った分散型のバージョン管理システムである。PythonとRustで書かれ、GPLv2以降のライセンスで公開されている⁸。Meta（当時のFacebook）がMercurialを大規模なモノレポに合わせて拡張したものが、のちのSaplingになった⁵。公式のリリースの一覧にある最新は、2026年1月29日の7.2である⁸。

Fossil

Fossilは、SQLiteの作者のD・リチャード・ヒップが2006年に作った分散型のバージョン管理システムである。リポジトリを1つのSQLiteのデータベースのファイルに入れ、バグ管理・wiki・フォーラム・Webの画面を1つの実行ファイルに同梱する。SQLite自身の開発に使われている²⁷。ライセンスはBSDの2条項のものである。最新のリリースは2026年3月11日の2.28である²⁸。

Pijul

Pijulは、ピエール＝エティエンヌ・ムニエが作る、パッチの理論に基づく分散型のバージョン管理システムである。履歴を状態の並びとして持たず、順番を入れ替えても結果が変わらないパッチの集まりとして持つ。このため、同じ変更をどの順で取り込んでも同じ結果になり、チェリーピックの後に衝突が繰り返されない。衝突は解消されるまで状態として残る²⁹。Rustで書かれ、GPLv2で公開されている。2026年10月30日に1.0.0-beta.26が出ており、1.0は2026年11月3日の時点でまだ出ていない³⁰。

Darcs

Darcsは、デイヴィッド・ラウンディが2002年ごろに作った、パッチの理論に基づく分散型のバージョン管理システムである。Haskellで書かれ、Pijulが同じ考え方を引き継いだ³¹²⁹。最新のリリースは2025年1月の2.18.5である³¹。

Breezy

Breezyは、CanonicalのBazaarを引き継いで有志が開発する分散型のバージョン管理システムである。Bazaarの形式に加え、Gitのリポジトリも扱える。PythonとRustで書かれている³²。最新のリリースは2026年10月31日の3.3.24である³²。

Radicle

Radicleは、Gitのリポジトリを中央のサーバーを置かずにピアどうしで共有する仕組みである。履歴はGitの形式のまま持ち、イシューやパッチのやり取りもリポジトリの中に記録する³³。最新のリリースは1.10.3である³⁴。

集中型

Subversion

Subversion（SVN）は、CVSの後継を目指して2000年に始まった集中型のバージョン管理システムで、Apacheソフトウェア財団が開発している⁶³⁵。ディレクトリの単位でチェックアウトでき、大きなバイナリを扱いやすい。2026年10月8日に1.15.0が出た³⁵。

P4

P4は、Perforceの集中型のバージョン管理システムで、以前はHelix Coreと呼ばれていた。大きなバイナリと巨大なリポジトリに強く、ゲームの開発で広く使われている³⁶。最新のサーバーの系列は2026.1である³⁶。

Unity Version Control

Unity Version Controlは、スペインのCódice Softwareが作ったPlastic SCMを、2020年にUnityが買収して名前を変えたものである。分散型と集中型のどちらの使い方もでき、ゲームの開発に向けた画面を持つ³⁷。

Diversion

Diversionは、ゲームと創作の開発に向けたクラウドで動く集中型のバージョン管理システムである。保存のたびに作業領域を同期し、ステージングとpushの段階を持たない³⁸。2026年7月のCEDECで、クリーチャーズが導入の事例を発表した³⁹。

Lore

Loreは、Epic Gamesが2026年6月にMITライセンスで公開した、集中型で内容アドレス方式のバージョン管理システムである。社内のUnreal Revision Controlから育ち、UEFN（Unreal Editor for Fortnite）に組み込まれている。コードと大きなバイナリを併せ持つ計画を主な対象とし、Rustで書かれている⁴⁰⁴¹。最新のタグは0.12.0である⁴²。

比較

外部リンク

• Redesigning source control at Anthropic
• Scaling Git at OpenAI
• Git
• Jujutsu（GitHub）
• Sapling
• GitButler
• gitoxide（GitHub）
• Mercurial
• Fossil
• Pijul
• Subversion
• Lore（GitHub）
• Oak

出典

1. Anthropic「Redesigning source control at Anthropic」2026年10月13日公開、10月15日更新。2026年11月3日閲覧。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰

2. Aaron Friel、Taylor Blau、Ted Nyman「Scaling Git at OpenAI」OpenAI、2026年11月2日。2026年11月3日閲覧。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²

3. Eleanor White、Victoria Dye「The bridge to agent-scale Git infrastructure」GitHub Blog、2026年10月。2026年11月3日閲覧。 ↩ ↩²

4. Vicent Martí「Git at any scale」Cursor、2026年8月18日。2026年11月3日閲覧。 ↩ ↩²

5. 「Sapling SCM」。2026年11月3日閲覧。 ↩ ↩² ↩³ ↩⁴

6. 「Version control」Wikipedia（英語版）。2026年11月3日閲覧。 ↩ ↩²

7. 「Git」Wikipedia（英語版）。2026年11月3日閲覧。 ↩ ↩² ↩³

8. 「Mercurial SCM」。2026年11月3日閲覧。 ↩ ↩² ↩³

9. 「git/git のタグ」GitHub。2026年11月3日閲覧。 ↩

10. 「Upcoming breaking changes」Git。2026年11月3日閲覧。 ↩

11. Andrew Nesbitt「This Week in Source Control: 28 October 2026」2026年10月28日。2026年11月3日閲覧。 ↩ ↩² ↩³ ↩⁴

12. 「Oak」。2026年11月3日閲覧。 ↩ ↩² ↩³

13. 「jj-vcs/jj」GitHub。2026年11月3日閲覧。 ↩ ↩² ↩³

14. 「jj-cli」crates.io。2026年11月3日閲覧。 ↩

15. 「facebook/sapling のタグ」GitHub。2026年11月3日閲覧。 ↩

16. 「GitButler」。2026年11月3日閲覧。 ↩

17. 「gitbutlerapp/gitbutler のリリース」GitHub。2026年11月3日閲覧。 ↩ ↩²

18. 「GitButler: $17 Million Series A Raised…」Pulse 2.0、2026年4月13日。2026年11月3日閲覧。 ↩

19. 「arxanas/git-branchless」GitHub。2026年11月3日閲覧。 ↩ ↩²

20. 「libgit2/libgit2 のタグ」GitHub。2026年11月3日閲覧。 ↩

21. 「eclipse-jgit/jgit のタグ」GitHub。2026年11月3日閲覧。 ↩

22. 「go-git/go-git のタグ」GitHub。2026年11月3日閲覧。 ↩

23. 「gix」「gitoxide」crates.io。2026年11月3日閲覧。 ↩

24. 「dulwich」PyPI。2026年11月3日閲覧。 ↩

25. 「isomorphic-git」npm。2026年11月3日閲覧。 ↩

26. 「GitoxideLabs/gitoxide」GitHub。2026年11月3日閲覧。 ↩

27. 「Fossil」。2026年11月3日閲覧。 ↩

28. 「Change Log」Fossil。2026年11月3日閲覧。 ↩

29. 「Pijul」。2026年11月3日閲覧。 ↩ ↩²

30. 「pijul」crates.io。2026年11月3日閲覧。 ↩

31. 「darcs」Hackage。2026年11月3日閲覧。 ↩ ↩²

32. 「breezy」PyPI。2026年11月3日閲覧。 ↩ ↩²

33. 「Radicle」。2026年11月3日閲覧。 ↩

34. 「radicle-dev/heartwood のタグ」GitHub。2026年11月3日閲覧。 ↩

35. 「Apache Subversion News」Apache Software Foundation。2026年11月3日閲覧。 ↩ ↩²

36. 「P4 Detect release notes 2026.1」Perforce。2026年11月3日閲覧。 ↩ ↩²

37. 「Unity Version Control」Unity Documentation。2026年11月3日閲覧。 ↩

38. 「Diversion」。2026年11月3日閲覧。 ↩

39. 「Modernizing Development Pipelines with Cloud-Native Version Control "Diversion" #CEDEC2026」DevelopersIO。2026年11月3日閲覧。 ↩

40. 「EpicGames/lore」GitHub。2026年11月3日閲覧。 ↩

41. 「Epic Games Announces Lore Open-Source Version Control System」Phoronix、2026年6月。2026年11月3日閲覧。 ↩

42. 「EpicGames/lore のタグ」GitHub。2026年11月3日閲覧。 ↩