Git Is Not Fine: Rethinking Version Control for Modern Workflows

バージョン管理の業界標準は、20年近くほとんど変わっていません。Gitはどこにでも存在しますが、Linuxカーネル向けに設計されたそのコアアーキテクチャが、現代の、反復的で、しばしば非線形な開発プロセスと完全には一致していないと感じる開発者が増えています。

「Git Is Not Fine」という議論を巡る最近の議論は、私たちがその限界を解決するのではなく、単にそれに対処する方法を学んだだけであることを示唆しています。スタックされたPRの管理から、インデックス（ステージングエリア）による摩擦まで、変更を追跡するために使用しているツールは、実際のコードの書き方とますます乖離しています。

The Friction of the Linear Mindset

Gitのアーキテクチャは、根本的にコミットのストリームに基づいています。しかし、現代の開発——特に大規模なmonorepoでは——決して直線的ではありません。開発者は、複数の機能を同時に開発していることが多く、あるパッケージにおける小さな修正が、別のパッケージの機能を実現するために必要になることがあります。

最近のHacker Newsの議論で一人の開発者が指摘したように、課題は単にブランチを切り替えることではなく、「ツリー状」のワークストリームを管理することにあります。

I work on one thing, but it causes changes in other package and I have no clear no way to say: this changes go to branch #1, this other set of changes to branch #2, and another small fix to branch #3. Branch #1 depends on the others... Switching branches is not a solution, cause all of this changes develop at the same time.

このような環境では、stashingやworktreesのような従来のGitワークフローは、しばしば不十分です。どの変更がどの論理的な作業単位に属するかを手動で追跡するという認知負荷は、生産性に対する大きな負担となります。

The "Muscle Memory" Fallacy

一般的な反論があります。Gitの複雑さは、単に学習曲線の問題であるというものです。多くの経験豊富な開発者は、rebasing、submodulesの管理、コミット履歴の書き換えは、単に「筋肉の記憶（muscle memory）」の問題であると主張します。

The way I'd handle rebasing stacked PRs/branches is to rebase the very last one. Then simply git branch -f a-branch <logical same point on rebased> for each of the others, done. It all became muscle memory.

しかし、この筋肉の記憶への依存は、問題を示唆しています。ツールの主要なインターフェースが、一般的なタスクを実行するためにユーザーに複雑なコマンドのシーケンスを暗記させる必要がある場合、そのツールはもはや作業を促進するものではなく、作業そのものになってしまっています。AI支援型コーディングの出現は、これをさらに複雑にしています。開発者は現在、主要な機能に集中しながら、LLMを使用して迅速なサイドタスクを実行しており、これがさらに断片化されたワークストリームを生み出しています。

Beyond Git: The Rise of New Alternatives

Gitの不十分さに関する議論は、前例がないわけではありません。この記事では、Metaのような企業が、monorepoの規模と複雑さを扱うために、Mercurialに基づいた社内システムを長年使用してきたことを強調しており、変更を追跡するより効率的な方法が存在することを示しています。

これにより、Jujutsu (jj) のようなツールの出現につながりました。これは、Gitの核心的な不満をいくつか解決することを目指しています。コミットを可変（mutable）として扱い、作業ディレクトリの状態がどのように追跡されるかを再考することで、jj はステージングエリアに関連する摩擦や「detached HEAD」状態を軽減しようと試みています。

Conclusion: Is Git Truly "Not Fine"?

Gitが「良くない」バージョン管理システムなのか、それとも単に私たちが使いこなせるようになったツールなのか、結果は同じです。ツールと現代の開発者のメンタルモデルとの間にギャップが存在しています。一部の開発者は現在のGitワークフローが特定の言語やプロジェクトの規模にとって十分であると感じていますが、他の開発者——特に大規模で分散された環境にいる人々——は、Gitのアーキテクチャの限界が避けられないボトルネックになりつつあることに気づいています。