Gitの次は？バージョン管理システムの未来を徹底予想

バージョン管理（Version Control）の今後について、私たちは今どのような局面に立っているのでしょうか。Gitがデファクトスタンダードとなって久しいですが、次世代のツールやワークフローがどのように進化していくのか、その展望についてまとめました。

これはCodevilleでのBramのアイデアを復活させて、さらに練り直したものだね。Codevilleは2000年代初頭のDVCS（分散型バージョン管理システム）全盛期に遡る初期の取り組みだ。Codevilleもストレージとマージに「weave」を使っていて、これはSCCS（さらにはTeamwareやBitKeeper）から来た概念。CRDTが導入される10年も前からあるけど、見た感じこの2つのコンセプトは相性が良さそうだね。WeaveがGitやMercurialみたいなヒューリスティックな手法より明らかに優れたマージ結果（衝突の減少）を出すって証明するのはいつも難しかった。テストケースに必要な編集履歴を理解するのが（少なくとも俺には）大変だったから。Bramがこの問題を諦めずに、いまだに新しいアイデアを試しているのはいいことだと思う。

3文目の重要なポイントはこれかな？「...バージョン管理にCRDTを使う。これはずっと前から期待されてたけど、まだ実現してない」 Pijulは既にあるし、何百、いや何千時間もエキスパートたちが苦労して作り上げてる。Bramもその一人なのは間違いないけど、この記事の書き方は、なんていうか「例のアレ」って感じがするな。

失敗しないマージって本当に良いことなのかな？マージの失敗って、単に「同じ場所が変更された」だけじゃなくて、意味論的なコンフリクトを知らせてくれることが多い。そういうのは、ちゃんと気づいて手動で対処したいよね。提案されてるシステムも何らかの形で対応してるんだろうけど、ざっと読んだ限りでは分からなかった。

これ、めちゃくちゃ短い。manyana.pyは473行の依存関係なしのPythonで（difflib, itertools, inspectをインポートしてるだけ）、そのうち実装部分は約240行で、残りはテストだね。

面白いアイデアだね。コンフリクトは改善できるかもしれないけど、個人的にはVCSの致命的な課題とは見てないな。本当に重要だと思うのは、特にGitにおけるスケーラビリティだ。リポジトリのサイズや更新頻度がGitの限界に来ていて、サーバー、クライアント、通信プロトコルのすべてで見直す必要があると思う。具体的にどうすべきかは分からないけど（笑）。でも、今いる中堅の有名テック企業では、まさに今その限界にぶち当たってるよ。

こういうのは、VCSを使ってるチームの規模ごとの分析から生まれるべきだと思う。1人、10人、100人、1000人規模のチームがマージコンフリクトで本当に直面してる問題は何なのか？それぞれの規模で何を一番重視してるのか？最近の「エージェントの爆発的増加（AIエージェントなど）」はどう影響するのか？例えば、1〜100人規模での経験から言うと、ここで挙げられてるようなコンフリクトは、コードのサブツリーを特定のチームに割り当てることでほぼ解決されてる。チーム間で調整して直交する変更を入れるし、放置されたブランチは避けるから、コンフリクトはあんまり起きないんだ。でも、エージェントが混じってくると、100人のチームがすぐ1000人規模になる。各人がマイクロコミットをするサブエージェントを使い始めたら特にね。アイデアとしては面白いけど、現実のデータがないと、解決すべき問題がはっきりしないままソリューションだけ出してる感じがする。コンフリクトは面倒だけど、心が折れるほど頻繁に起きるわけじゃないしね。

マージの見せ方の話は、履歴の持たせ方とは別問題な気がする。俺もGitのデフォルトは嫌いだけど、だからこそp4mergeをマージツールとして使って、4ペイン（左、右、共通ベース、マージ結果）で表示してる。これならコンフリクトの原因と解決方法がちゃんとわかるし。この問題を解決するためにVCS自体を乗り換える必要があるのか、よくわからないな。

CRDTにフォーカスするメリットがよくわからない。コンフリクトの意味論的な問題はどっちにしろ残る。一貫した結果と、少しマシなコンフリクトの説明は得られるだろうけど、変更が変に入り混じる可能性があるなら、それは改善とは言えないと思う。俺は完全にリベース信者だ。マージコミットは絶対に避けるべきで、すべてのコミットはファストフォワードであるべきだし、単独でロールバックできる単位にすべきだ。コミットも小さくね。Gitflowはアンチパターン。長期間残るブランチはパッチリリース用であって、機能開発用じゃない。これがVCSの未来だとは思えないな。Jujutsu（やGerrit）はGitの本当の問題、つまり一つの変更に対して複数のリビジョンが発生する問題を解決してくれる。フィードバックを受けてコミットチェーンをリベースしなきゃいけない時の苦痛を和らげてくれるからね。

バージョン管理にCRDTは使えないよ。コンフリクトが起きることこそがバージョン管理の本質なんだ。二人の開発者がコードを根本的に違う方向に変えようとしたとき、マージコンフリクトが起きることで、マージやリベースをする人がどっちの意味論を残すか選べるようになる。CRDTだとゴミみたいなコードが生成されるだけで、根本的に間違った解決策だ。マージコンフリクトのUXを良くしたいなら、Git上のツールや他のVCSでより良い見せ方をしてるやつがいくらでもある。それは下層のデータ構造とはほとんど関係ない話。チェリーピックやリバートが難しくなる時点で、アプローチが間違ってるってわかるはずだ。Gitならそんなの超簡単なのにね。

みんな、mergirafってツールが最高だよ。これを使ってから、最後にいつ手動でリベースしたか思い出せないくらいだ。