My Experience With Jujutsu (jj)

Over the past few months, I've been experimenting with Jujutsu, a modern version control system, written in Rust, that challenges the traditional Git workflow. After using Git for a while, switching to Jujutsu felt so different at first. It is the only version control system (VCS) I have ever used after all, but jj has really changed how I think about committing code and planning changes.

The Culture Shock

When I first started using Jujutsu, I felt so lost. Commands felt foreign, and my muscle memory from Git kept getting in the way. The mental model and approach are different. Jujutsu does things in its own way, which I really came to like, to be honest. How the tool approaches the act of saving work is incredible. I was used to Git's staging area (the "index"), where you carefully select what goes into a commit. Jujutsu throws that away, and at first, I wasn't sure about this.

No Staging Area

It took me a while to appreciate that you're always working on top of a commit. Every change you make is always part of the current working copy commit, of which can just be a descriptionless commit (a commit with just a hash) until described or, the empty commit can be described before making any changes.

This sounds chaotic, I know, but it's actually the beauty of it. Rather than thinking of commits as snapshots of what you've done, think of them as the plan for what you're about to do. You describe your intent before implemention. This flips the traditional Git workflow on its head. I really can't tell you how much more focused and intentional my work has become since adopting this mindset. It's even given me a platform to think about my commit messages and the purpose of my changes in a more structured way. When you use jj describe to write a commit message before making changes, you're establishing a contract with yourself about what you're going to accomplish. Then you actually do it. This forces intentionality into your workflow in a way that Git just doesn't. No chore commit messages that implement micro features that will probably get rejected in code review.

Git Compatibility

It wouldn't make sense to abandon Git entirely, too many teams rely on it. Jujutsu has great compatibility with Git repositories. You can initialize a Jujutsu workspace on top of an existing Git repo, work completely in Jujutsu, and then export your changes back to Git. Your teammates would have no idea you switched. They'd see normal commits in the Git history.

Describe First, Implement Second

A paradigm shift that I feel would make Jujutsu special is the writing of your commit message first, then making the changes later.

In Git, you make changes, then scramble to write a coherent commit message that explains what you did. With Jujutsu, you describe what you're going to do, then do it. This creates a natural feedback loop where your implementation stays true to your stated intent.

Think about it from a discipline perspective. When you've already said "I'm going to refactor the user authentication module to use a cleaner token-based approach," you're much more likely to stay focused on that specific task. You've made a commitment. You can't accidentally mix in unrelated changes because you've already defined the scope of your work.

This approach encourages better code organization, much clearer commits, and less technical drift during development sessions.

The Git Problem

Here's something I've experienced with Git many times. You start working on a project, make changes for a while, then step away. When you come back a week later, you've forgotten what you were doing. Maybe you have some uncommitted changes, maybe you have some scattered commits, but you've lost context.

With Git, not having a clear plan upfront makes it pretty easy to lose track of your intent. You end up with vague commit messages because you can't really remember what the original plan was.

Jujutsu acknowledges this reality and compensates for it. Even if you don't have extensive planning before you start, the fact that each commit has a description that you can write upfront gives you an anchor point. When you come back to your code after a break, you can see what you said you were going to do. It's like leaving yourself detailed notes.

And if you need to iterate without a solid plan? Jujutsu is forgiving. You can still work fluidly, squashing changes, reordering commits, and refactoring your history as you go. But you're always working within the framework of described commits, so there's still structure and intentionality.

What's next?

I cannot wait to see what happens when Jujutsu reaches a stable release and starts gaining adoption in teams that prioritize organized, disciplined development practices. This is a tool built for developers who care about clarity, who want their commit history to tell a coherent story, and who recognize that good code comes from good planning.

For teams that operate on a foundation of clear communication and deliberate change management, Jujutsu is a force multiplier. It enforces better practices naturally, without feeling restrictive. One might argue it makes it harder to accidentally create technical debt through scattered changes.

The best part is that it does all this while maintaining perfect interoperability with Git. There's no cost to trying it, no risk of breaking team workflows, no friction in adoption. You can start using Jujutsu tomorrow and have perfect Git compatibility the day after.

I'm genuinely excited about this project and its potential to influence how version control systems evolve. In a world where Git has dominated for nearly two decades, I think the fact that Jujutsu is even possible is inspiring.

If you're interested in learning more about Jujutsu, head over to the official documentation at jj-vcs.github.io. Start with a personal project or a clone of an existing repository. Experience the workflow for yourself. You might surprise yourself with how quickly the paradigm shift starts to make sense. I'll be looking more into how jj manages conflicts. This is bound to be an interesting experience as, I've seen it can skip merges and have you fix them later.

Happy coding!