Is Git Still Enough? The Debate Over Modern Version Control
For over a decade, Git has been the undisputed industry standard for version control. Its speed, distributed nature, and powerful branching model have shaped how we build software. However, as project scales increase and development patterns evolve—particularly with the rise of monorepos and AI-assisted coding—a growing segment of the developer community is starting to ask: Is Git actually fine?
Recent discussions, sparked by critiques of Git's ergonomics and the emergence of new tools like Jujutsu (jj), suggest that while Git is functionally complete, its user experience often lags behind the needs of modern, high-velocity engineering teams.
The Friction of Modern Workflows
One of the primary criticisms of Git is its rigidity when handling "stacked" changes. In a high-output environment, developers often work on multiple interrelated features simultaneously. This creates a tree-shaped workstream rather than a linear one.
When a developer needs to split changes across multiple branches—perhaps a core API change in one, a feature implementation in another, and a quick bug fix in a third—Git's branch-centric model can become cumbersome. As one developer noted:
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... Switching branches is not a solution, cause all of this changes develop at the same time.
This friction is amplified in monorepos, where the blast radius of a single change can touch multiple packages, making the process of isolating and moving commits between branches a tedious exercise in "Git wizardry."
The Rise of Jujutsu (jj) and the Quest for Mutability
To address these pain points, tools like Jujutsu (jj) are gaining traction. The core argument for these new systems is often centered on a few key improvements:
- Better Handling of Uncommitted State: Git's index (the staging area) is often viewed as a hurdle. New tools aim to track state more fluidly, reducing the risk of losing work during complex rebases.
- First-Class Support for Stacked PRs: By treating commits as more mutable and flexible, these tools make it easier to evolve a series of dependent changes without the "ceremony" of constant manual rebasing.
- Reduced Cognitive Load: The goal is to move away from a system where complex operations require a deep understanding of the internal plumbing of the DAG (Directed Acyclic Graph).
The Counter-Argument: "Git is Fine"
Despite these critiques, a significant portion of the community remains unconvinced. The "Git is fine" camp generally falls into three categories of thought:
1. The "Muscle Memory" Perspective
Many senior developers argue that the perceived complexity of Git is simply a learning curve. Once the commands for rebasing and branch management become muscle memory, the friction disappears. For these users, the complexity is a feature of the power Git provides, not a bug.
2. The Automation Solution
Rather than switching tools, some developers solve Git's verbosity through automation. This includes writing custom shell scripts to handle stacked rebases or using advanced IDE integrations like Magit to streamline the workflow.
3. The AI Bridge
Interestingly, the emergence of LLMs has provided a temporary reprieve for those who find Git daunting. Many developers now use AI to generate the exact sequence of complex Git commands needed for a specific rebase or rewrite, effectively using AI as a translation layer between their intent and Git's arcane syntax.
Synthesis: Tooling vs. Process
The debate over Git's adequacy reveals a deeper tension in software engineering: the trade-off between a robust, distributed system and a streamlined developer experience.
While some argue that needing complex tools to manage Git is a sign of "overengineering" and a failure of process, others argue that the tools should evolve to match the reality of how developers actually work—especially when AI-driven coding allows for a much higher volume of simultaneous changes.
Whether Jujutsu eventually displaces Git or remains a niche tool for power users, the conversation highlights a critical truth: the way we manage code is just as important as the code we write. As our workstreams become more "tree-shaped," the tools we use to manage them must either adapt or risk becoming the bottleneck.