I lost three commits on a Friday afternoon. A rebase gone sideways, no reflog entry I could find, no undo button. Just gone. I've shipped distributed systems handling millions of requests, but Git's porcelain still makes me hold my breath during complex history rewrites. Every developer has a Git horror story. Most of us have several.
That's why Jujutsu — a Git-compatible version control tool built at Google — caught my attention. Not because it promises to replace Git (we've all heard that pitch). Because it sits on top of your existing Git repos and fixes the exact workflows that cause the most pain. With over 27,000 stars on GitHub and growing fast, jj is the first credible attempt at better version control I've seen in a long time.
What Is Jujutsu and Why Should You Care?
Jujutsu (you invoke it as jj on the command line) is a distributed version control system created by Martin von Zweigbergk, a software engineer at Google. It's fully open source and written in Rust. But here's what separates it from every other "Git killer" that's come and gone: it doesn't ask you to abandon Git.
Jujutsu uses Git's on-disk format. Reads and writes the same .git directory. Your teammates keep using git while you use jj on the same repository. Commits you create with Jujutsu are real Git commits. Push them to GitHub. Nobody knows the difference.
This is a fundamentally smarter adoption strategy than anything Mercurial, Fossil, or Pijul ever attempted. Instead of asking the entire world to switch, Jujutsu says: "Keep your Git infrastructure. Keep your GitHub. Keep your CI. Just use a better interface."
As Martin von Zweigbergk explained in Google's open source blog announcement, the goal is to make developers more productive with a simpler, safer, more powerful interface to version control — while maintaining full Git compatibility.
Does Jujutsu Actually Replace the Git Staging Area?
Yes. And this is probably its most divisive design decision.
In Git, you have three states: working directory, staging area (index), and committed. You git add files to stage them, then git commit to finalize. Jujutsu eliminates the middle step entirely.
Your working directory is your current commit. Every change you make is automatically part of the latest commit. No staging area. No git add. No forgetting to stage a file and shipping an incomplete commit.
I know what you're thinking: "But I use the staging area to craft precise commits!" Fair. So did I. Jujutsu handles this differently — you split commits after the fact using jj split, which is both more flexible and harder to mess up. Instead of carefully staging hunks before committing, you commit everything and then surgically divide it into logical units.
Having worked with teams where junior engineers regularly forget to git add new files — leading to broken CI runs that waste everyone's time — this design choice makes sense to me. The staging area was always a leaky abstraction. Most developers either stage everything or nothing. Jujutsu just acknowledges that reality.
This tracks with something I've been thinking about regarding how AI coding agents are changing developer workflows. The best tools match how people actually work, not how we wish they worked.
Can You Undo a Merge or Rebase in Jujutsu?
This is where Jujutsu earns its keep. Every single operation — merges, rebases, commit amendments, branch moves — is recorded in an operation log. Think of it as an undo history for your entire repository state, not just individual files.
The command is jj undo. That's it. Botched a rebase? jj undo. Merged the wrong branch? jj undo. Accidentally rewrote history? jj undo.
Git technically has git reflog, but let's be honest: reflog is a forensics tool, not an undo button. Finding the right entry, figuring out which SHA corresponds to which state, running git reset --hard to recover — that's a multi-step process that requires you to already understand Git's internals. I've seen senior engineers with a decade of experience hesitate before touching reflog.
Jujutsu's operation log captures the entire repository state at each point, not just where HEAD pointed. It's closer to Time Machine for your repo than anything Git offers natively.
The best safety net is one you never think about until you need it.
This alone would be worth switching for teams where a bad rebase costs hours of recovery time. I've shipped enough features to know that the tools preventing catastrophic mistakes — not the ones with the most features — are the ones that actually improve team velocity.
How Does Jujutsu Handle Branches and Conflicts?
Jujutsu rethinks two things Git developers deal with constantly: branches and merge conflicts.
Branches as labels, not history. In Git, branches are tightly coupled to commit history. In Jujutsu, as Jonathan Corbet's analysis on LWN.net explains, branches are lightweight mutable labels that point to commits. You move them around freely without the anxiety of "detached HEAD" states. Branch management starts to feel like how you think about branches — as bookmarks to interesting points in your work — rather than as structural elements you're afraid to touch.
First-class conflict handling. When a merge conflict happens in Git, you're stuck. Can't commit. Can't easily switch tasks. You have to resolve it right now. Jujutsu does something I genuinely didn't expect: conflicts are stored as part of the commit graph. A conflicted state is just another commit. You can work with it, come back to it later, or resolve it whenever you want.
I've lost count of the number of times I've been mid-conflict-resolution when something urgent lands in Slack and I have to stash everything, abandon the merge, and context-switch. Jujutsu just lets you walk away and come back. The conflict is recorded, not lost.
For teams dealing with complex system architectures and distributed workflows, this kind of flexibility isn't a nice-to-have. It changes how you plan your work.
Is Jujutsu Ready for Production Use?
Let me be direct about where Jujutsu stands today. The GitHub repository shows 27,200+ stars, over 11,000 commits, and roughly 980 forks. That's serious traction for a developer tool. Google uses it internally, which is both a credibility signal and a practical indicator that it handles real-world scale.
But there are real limitations. The ecosystem is young. IDE integrations are thin compared to Git's decades of tooling. Some Git hosting features (like GitHub's pull request workflow) need workarounds. And the community, while passionate, is a fraction of Git's.
Here's my honest read after spending time with it: Jujutsu is production-ready for individual developers and small teams who live on the command line. For large organizations with deeply embedded Git workflows, CI integrations, and hundreds of developers? Not yet. The Git compatibility layer means you can use it, but you'll hit edges where the abstraction gets thin.
The project is also worth watching because of its contributor base. The core team at Google is strong and the Rust codebase is clean. But like any open-source tool, long-term survival depends on sustained investment and community growth.
I should address the elephant in the room: some sources online claim Bram Cohen (creator of BitTorrent) is a major force behind Jujutsu. While Cohen has contributed to the project and influenced its design thinking, the project lead is clearly Martin von Zweigbergk. I'd rather be transparent about this than let a misleading narrative persist. The tool stands on its own merits.
This kind of honesty matters in developer tooling. I've written before about how technical debt silently accumulates when teams adopt tools based on hype rather than substance. Jujutsu deserves evaluation on what it actually does, not on who's attached to it.
The Real Question: Will Jujutsu Unseat Git?
No. And that's the wrong question.
Git won't be "unseated" any more than TCP/IP will be unseated. It's infrastructure. The interesting question is whether Jujutsu becomes what most developers actually interact with while Git stays the underlying protocol.
Think about it: most developers don't write raw HTTP requests. They use libraries and frameworks. Jujutsu is positioning itself as that abstraction layer for version control. You get Git compatibility, Git hosting, Git CI integration. You just stop dealing with Git's worst UX decisions.
My prediction: within two years, jj will be the default version control interface for at least one major open-source project with 1,000+ contributors. Not because Git is bad at what it does, but because Jujutsu is better at what developers actually need to do day to day. The staging area will be the first thing to go. Undoable operations will become table stakes. And a generation of developers will wonder why version control was ever this hard.
If you're building developer tools, building teams, or just tired of holding your breath every time you run git rebase -i — go clone the repo and try jj on a side project this week. The future of version control isn't about replacing Git. It's about finally making Git usable.
Originally published on kunalganglani.com
Top comments (0)