For over a decade, Git has been the de facto standard for version control. It’s fast, flexible, and ubiquitous—but also famously opaque, with a steep learning curve and workflows that often confuse even experienced developers. But there’s a new competitor on the block: Jujutsu1.
Aside - why use version control
I'm continually surprised at how many analysts or analysis-adjacent people don't know any version control system (VCS). It was once a non-negotiable skill for bioinformatics and data science (along with SQL), but it seems to have dropped off the map. It's especially absent in fields like biostatistics, where many practitioners "collaborate" by emailing files to each other. Perhaps it's because there's too much else to know; perhaps it's because version control "looks" like software engineering. But actually, it's a basic and critical tool for anyone who writes code:
1. It saves your work locally and remotely. You won't have to worry about losing a file or accidentally deleting anything.
2. It allows teams to work on the same project in an organised and consistent way. No one's work will be overwritten.
3. It allows you to track changes and progress.
4. You can fork off different versions for experimentation without any fear of corrupting the original version or losing work.
5. You can integrate things like testing, deployment, or code reviews, to just happen automatically and seamlessly.
In short, if you don't use version control, start doing it now.
But what's wrong with Git?
There's a long history of version control systems, and many (most?) of the earlier choices were opaque, difficult and cumbersome. (Remember Arch, Bazaar, CVS, Subversion? And those were some of the better options.) But with the arrival of Git - and Mercurial to some extent - it felt like the problem had been solved. Git was so much better than the competition and a lot of default infrastructure (e.g. Github) sprang up around it.
But, actually, Git could still be much better.
1. Git wasn’t built with usability in mind. Some commands are arcane, inconsistent, and often don’t mean what you think they mean.
2. There are lots of ways that Git makes it too easy to do the wrong thing, to shoot yourself in the foot. To quote, "Git assumes you know exactly what you're doing. Most people don’t and shouldn’t have to."
3. Cleaning up Git repo history is fragile and feels risky.
4. Collaboration is a bit fragile. Once again, it's easy to shoot yourself in the foot.
5. The mental model of how Git works is very complicated and exposes a lot of internal logic.
6. As a result, most developers don't have a strong idea of how Git works. They just have a handful of commands they’ve learned over the years, enough to get by.
You shouldn’t just adopt another tool because of marginal gains. But the pain points with Git are such that it makes sense to look for alternatives.
So what Is Jujutsu?
There are several answers to this, coming from several different directions.
Jujutsu (command-line tool: jj) is a new version control system, that aims to combine the power of Git with a significantly improved developer experience.
Jujutsu is a user-friendly front-end that uses other version control systems on the backend, as storage.
Rather than building practices on top of a version control system, Jujutsu tries to incorporate workflow and best practices into simple commands.
There are some caveats, but we'll get to those.
Comparing Jujutsu & Git
An easy point to start is with a straight-up, head-to-head comparison at the command level. I've deleted some entries where the tools are more or less equivalent.
Jujutsu's working model
Much of the above is a big "so what". The syntax is similar if simpler. But the ideas behind it are different.
Jujutsu leads with the idea is that version control should prioritize safe, understandable history. Every change you make - committing, rebasing, amending - is tracked immutably. You never lose information.
The Working Copy is a First-Class Citizen. Jujutsu uses a real commit to represent the working copy. Any edit you make on disk is immediately reflected in the current commit. You don't have to tangle with `git stash` to manage multiple working copies. In most version control systems, as soon as you edit a file locally, that new change is in a kind of limbo state outside of the system and has to be managed separately.
Actually, everything is a commit and "bookmarks" are pointers to specific commits. This is a broader and simpler concept than Git.
Merge conflicts are a common source of pain in Git. Jujutsu tries to make collaboration less error-prone by using conflict-free branching and a cleaner approach to synchronization. If a merge results in conflicts, information about those conflicts will be recorded in the commit(s). The operation will succeed and you can resolve the conflicts later. No more being stuck having to fix a horde of conflicts before you can actually finish a merge.
If there's a single broad idea, it's that Jujutsu tries to match how developers work and their intuitions, making the common, safe behaviours easy and the risky behaviours hard if not impossible.
The caveats
While Jujutsu advertises itself as a version control system - and has it's own commands and infrastructure and potential to operate as a standalone VCS - it is currently practically functioning just as a user-friendly face to other VCSs. That's still a great advantage.
And, again in reality, it's practically a frontend just to Git. That's where most of the development effort has gone.
The idea of compatibility with Git needs some careful wording. From my experience, Jujutsu is compatible with a remote Git repo (e.g. use Jujutsu locally and push to Git repo). Using both Git and Jujutsu on a local working copy is a far more complicated issue, and there are some uncertainties.
Jujutsu is stable and largely feature-complete, but some more marginal cases (e.g. submodules, git-lfs, email-based workflows) aren't supported as yet.
Realistically, everyone else in the world is still using Git. So for the near future at least, Jujutsu is going to play nice with Git, which erodes some of its usefulness. For example, there's support in Jujutsu for branches, even though "branch" isn't a distinction in Jujutsu.
Pointers
There's a growing body of instructional material for Jujutsu out there.Some recommendations:
https://github.com/jj-vcs/jj: The official repo. Instructions dive straight in immediately without a lot of background
https://jj-vcs.github.io/jj/latest/tutorial/: The official tutorial. A bit better but still starts in the middle.
https://neugierig.org/software/blog/2024/12/jujutsu.html: A short, but more from-first-principles introduction. A good place to start.
https://steveklabnik.github.io/jujutsu-tutorial/: A lengthier tutorial, in progress.
https://v5.chriskrycho.com/essays/jj-init/: A thought piece about mental models and the motivations behind Jujutsu, followed by some instructions.
Fun fact - this is apparently how the word is actually spelt, not jiu jitsu