TL;DR:

  • Jujutsu (jj) is a Git-compatible VCS developed at Google that works on top of your existing Git repos
  • Its key insight: every working copy change is automatically a commit, so you never lose work and rebasing is trivially reversible
  • Conflict handling is fundamentally different — conflicts are stored in the commit graph and resolved later, not blocking you at the point they occur

Git is three decades old this year. It’s ubiquitous, powerful, and deeply confusing in ways that experienced developers have learned to work around rather than through. Jujutsu — usually referred to as jj — is a version control system developed originally at Google that addresses the genuinely difficult parts of Git without abandoning compatibility with it.

It’s not a fresh-start VCS. It works on top of Git’s storage format and interoperates with GitHub, GitLab, and any other Git host. But the mental model it exposes to users is significantly different, and for many developers who’ve tried it, it’s hard to go back.

The Core Insight: The Working Copy Is Always a Commit

In Git, the working directory is a special state. You accumulate changes, then decide when to commit them. Until you commit, the working directory is mutable and somewhat fragile — it can be accidentally cleared, it’s excluded from operations that work on commits, and it’s where most newcomers lose work.

In Jujutsu, the working copy is always a commit. Changes you make are automatically recorded in an uncommitted-but-tracked change. There’s no staging area. There’s no distinction between “my uncommitted work” and “commits I’ve made.” Everything is in the commit graph from the moment you save a file.

This sounds like a small difference. Its implications are large. Because there’s no special working directory state, you can:

  • Easily edit any previous commit without a disruptive git rebase -i flow
  • Abandon a change and come back to it without stashing
  • Move changes between commits using jj squash, jj split, and jj move
  • Always have a recoverable point for anything you’ve typed, because it’s all in the graph

Conflicts Are First-Class

In Git, when a rebase encounters a conflict, it stops. You’re dropped into a conflict resolution state where you have to resolve the conflict before the rebase can continue. If you have 12 commits to rebase and the third has a conflict, you’re stuck at the third.

Jujutsu handles conflicts differently. Conflicts are stored in the commit graph itself. When a rebase hits a conflict, Jujutsu records the conflict in the commit and continues rebasing. You end up with a commit graph where some commits contain conflicts — but the rebase finishes, and you can resolve conflicts at your own pace, in whatever order makes sense.

This is especially useful for large rebases on long-running feature branches, or when resolving conflicts requires context from later commits. Instead of getting blocked at commit 3 of 12, you finish the rebase, see the full picture, and resolve conflicts with all the context available.

Getting Started: It’s a Thin Layer Over Your Existing Repo

You don’t need to migrate your repository or convince your team to switch. Install jj, run jj git init --colocate in your existing Git repo, and you can start using jj commands immediately. Under the hood, jj is writing to the same Git object store. You can switch between git and jj commands freely.

# Install (macOS)
brew install jj

# Initialise in existing git repo
cd your-project
jj git init --colocate

# Basic workflow — check status
jj status

# Describe the current working copy change
jj describe -m "Add login form validation"

# Create a new empty change to start fresh work
jj new

# Push to GitHub (same as git push)
jj git push

The learning curve for basic usage is comparable to learning Git — a few core concepts and a handful of commands. The payoff comes when you hit the situations where Git gets painful.

Practical Operations That Become Easy

Editing a previous commit without disrupting your current work:

jj edit <change-id>
# Make changes to files
jj new  # return to where you were

Splitting a commit into two:

jj split <change-id>  # interactive selector for which files go in each commit

Moving changes between commits:

jj squash --from <change-id> --into <other-change-id>

Reordering commits:

jj rebase -r <change-id> --after <other-change-id>

Compare this to the equivalent git rebase -i flow with its interactive editor, the need to re-amend commits, and the risk of conflicts blocking the process.

Where It’s Getting Adopted

Google uses Jujutsu internally for a significant portion of its codebase. Several prominent open-source projects and developer tool teams have migrated to jj for their own development workflows. Mozilla’s Servo project and the Nushell team both use it. The Rust community has seen notable uptake.

In 2026, the tool has reached a level of stability and documentation quality where it’s a reasonable choice for individual developers and small teams willing to invest an afternoon in learning something new.

When to Stick With Git

If your team uses a GUI-based Git workflow (GitHub Desktop, Tower, SourceTree), jj doesn’t yet have equivalent GUI tooling — it’s primarily a terminal tool. If you’re on Windows and need tight IDE integration, compatibility varies by editor. If your team isn’t interested in changing tools, using jj solo on a shared Git repo creates no problems for your teammates — they never need to know.

For individual developers who spend meaningful time on rebases, cherry-picks, and commit archaeology, jj is worth the hour it takes to get comfortable with it.