The Future of Version Control: Beyond Git Conflicts | UData Blog

A project called Manyana landed on Hacker News this week with 531 points and nearly 300 comments. Its premise: Git's merge conflicts aren't inevitable — they're a design choice, and a better design is overdue. The project uses CRDTs (Conflict-Free Replicated Data Types) to build a version control system where merges never fail. For development teams that have spent years cursing three-way merge conflicts, the thread was a mix of excitement and healthy skepticism. The underlying idea is sound, and it's worth understanding what it means for how software teams will work.

Why Git Merge Conflicts Are a Solved Problem Waiting to Happen

Git's merge algorithm is elegant and has served the industry well for 20 years. But it has a fundamental limitation: when two branches touch the same region of a file, Git stops and demands human resolution. The conflict markers it produces — the infamous <<<<<<< and >>>>>>> blocks — show you two opaque text blobs. You have to mentally reconstruct what each side was trying to do, resolve the conflict, and hope you got it right.

This is a genuine tax on development velocity. In a 2024 study of engineering teams at mid-to-large software companies, developers reported spending an average of 3.5 hours per week on merge conflict resolution. For teams with many concurrent feature branches — a common pattern in fast-moving product organizations — this compounds significantly. More branches, more developers, more conflicts, more time lost.

The deeper problem is that merge conflicts create pressure against certain development patterns. Long-lived feature branches accumulate more conflict potential, so teams either merge frequently (reducing the value of feature isolation) or deal with painful integration at the end of a sprint. Neither is ideal. The conflict model shapes how teams work, often in ways that constrain their options.

What CRDTs Change About Merging

CRDTs are data structures with a mathematical property: they can always be merged, regardless of order, without conflicts. Two replicas of a CRDT, modified independently, produce the same result when merged — no matter which merge happens first. This is the property that powers collaborative editing in tools like Figma, Notion, and Google Docs. When two people edit the same paragraph simultaneously, the document doesn't crash or produce conflict markers. It merges both edits automatically.

Manyana applies this to version control. The core insight: treat source code as a CRDT, where line positions are permanent rather than relative to surrounding lines. When two branches insert code at the same location, the CRDT picks an ordering deterministically and keeps it. The merge always produces a result. The question shifts from "did this merge succeed?" to "is this merged result what we intended?"

The Manyana project introduces something called informative conflict presentation. Instead of two opaque blobs, you see a structured explanation of what each side did:

• Left branch deleted lines 5–12
• Right branch added a line at position 8 (inside the deleted range)
• Result: merged, with a conflict flag that explains the overlap

You still need to review the conflict — but you're reviewing with full context about what happened, not inferring it from the diff. That's a meaningfully different cognitive task.

The Practical Implications for Development Teams

If CRDT-based version control matures to production use, several current pain points change character:

Long-lived branches become less dangerous

The conflict risk of a month-old feature branch is a known problem. Teams manage it with "keep branches short" policies that work inconsistently in practice — features don't always fit in two-day windows. With merges that always succeed and conflicts that explain themselves rather than blocking, the calculus around branch lifetime changes. The penalty for letting a branch live longer decreases.

Merge queues and integration branches simplify

A significant portion of CI/CD complexity in high-velocity teams exists to manage merge order and prevent conflicting merges from hitting main simultaneously. Merge queues, serialized merges, and integration branches all address variants of "two branches conflict." When merges never fail by definition, some of this infrastructure becomes unnecessary.

Conflict review replaces conflict resolution

The shift in developer workflow is meaningful. Currently, resolving a merge conflict requires understanding both branches deeply enough to produce a correct synthesis — it's a mini code review plus a judgment call. With CRDT merging, the synthesis happens automatically. The developer's job is to review the result and confirm it's correct — a different task, and usually a faster one.

What the Skeptics Are Right About

The Hacker News thread included substantive pushback, and it deserves honest treatment.

Git semantics are deeply embedded. The tooling ecosystem around Git — GitHub, GitLab, Bitbucket, every CI system, every IDE integration — is built on Git's specific data model. A CRDT-based VCS isn't a Git extension; it's a replacement. The migration path for existing repositories and the integration story for existing tools are unsolved at the level of market adoption, even if the core technology is sound.

Automatic merges can still be wrong. A merge that succeeds technically can produce code that's semantically incorrect. Two branches that both modify a function — one changes the logic, one changes the signature — might merge cleanly at the text level while producing code that doesn't compile or doesn't behave correctly. CRDT merging solves the text conflict problem; it doesn't solve the semantic correctness problem. That still requires human review.

The line-ordering permanence trade-off has costs. In Manyana's model, line positions are permanent — once code is inserted at a position, that ordering is preserved through all future merges. This prevents a class of conflict, but it also means that concurrent insertions at the same point produce an ordering that neither author chose. For code where ordering matters (initialization sequences, middleware order, CSS cascade), this requires careful attention.

Where This Is Heading

CRDT-based version control is not replacing Git next year. But it represents a genuine research direction that addresses real developer pain, and Manyana is the clearest proof-of-concept to date that the approach is technically coherent. The ideas in it are likely to influence how Git itself evolves, how merge tools are built, and how collaborative coding environments work.

The broader trend is real: version control is getting smarter about understanding code structure rather than just text. Tools like Semantic Merge, Difftastic, and now CRDT-based systems are all attacking the same problem from different angles — merge conflicts that arise from textual overlap, not logical conflict. The best merge is one that understands what the code means, not just what the bytes are.

For development teams today, the practical takeaway is to watch this space and invest in practices that reduce conflict friction now: shorter-lived branches, regular rebasing, clear ownership of modules to reduce parallel edits, and automated conflict detection in CI. These habits will pay off regardless of which VCS wins — and they'll make the migration easier when CRDT-based tools are ready for production use.

How UData Helps Teams Ship Faster

Version control friction is one symptom of a broader problem: development processes that add overhead without adding value. UData works with software teams to identify and remove the bottlenecks slowing delivery — whether that's merge overhead, slow CI pipelines, unclear review processes, or tooling that doesn't fit the team's workflow.

We provide senior engineers who build and maintain the development infrastructure that lets product teams move fast: CI/CD pipelines, automated testing frameworks, code review tooling, and the engineering culture practices that compound over time. We also outstaff experienced developers who slot into existing teams and raise the engineering quality bar without months of hiring and onboarding.

If your team is spending meaningful time on merge conflicts, integration overhead, or development process friction, that time is recoverable. The tools and practices to get it back exist today — and better ones are coming.

Conclusion

CRDT-based version control is not a finished product — it's a proof of concept for a better approach. But the problem it's solving is real, the mathematics behind it are sound, and the developer experience improvements it promises are meaningful. Merges that never fail, conflicts that explain themselves rather than demanding reconstruction, and freedom from the "keep branches short" constraint are genuine improvements over the current state.

Git will be with us for years. But the next generation of version control is being designed, and the ideas coming out of projects like Manyana will shape what it looks like. The teams paying attention now will be best positioned to adopt it — and to improve their development processes in the meantime.