Most of us have a Git ritual we never examine. You edit a file, run git add -p, squint at hunk boundaries, commit, realize the message was wrong, and amend. Half the commands exist to manage a gap between what's on disk and what's in the repository.
Jujutsu (jj) removes the gap. It's a Git-compatible version control system written in Rust, started by Martin von Zweigbergk, and it treats your working copy as a commit like any other. The latest release as of this writing is 0.46.0, published on 7 October 2026.
The working copy is a commit
In jj, every command snapshots your edits into the current commit automatically. There is no index and no git add. jj status shows what changed, and jj describe edits the commit message of whatever you're working on — including commits buried in history.
When you're done with a change, jj new starts a fresh empty commit on top. That's the whole loop:
jj describe -m "fix: handle empty config"
# edit files
jj new
Because the working copy is a real commit, it has a commit hash that changes every time you touch a file. It also has a change ID — a short, stable identifier that survives rewrites. Rebase a change, amend it, reorder it: the change ID stays put while the hash moves. That single design choice is why the rest of the tool feels different.
Conflicts are data, not failures
Git stops a rebase when it hits a conflict and leaves you in a half-finished state. Jujutsu records conflicts inside commits and keeps going. You can rebase a conflicted commit, stack more work on top, and resolve it later. When you rewrite a commit, its descendants are rebased automatically, and bookmarks pointing at them move too.
The safety net is the operation log. Every command that touches the repo is recorded, and jj undo reverts the last one. jj op log shows the history of operations, and jj log --at-op=<id> lets you look at the repository as it stood at any earlier point. It's closer to a database transaction log than to Git's reflog.
Branches become bookmarks
jj has no "current branch." New commits don't move a branch pointer, because there's nothing to move — the commit graph keeps every visible head alive. When you're ready to publish, you create a bookmark and push it:
jj bookmark create my-fix -r @-
jj bookmark track my-fix
jj git push
Note the -r @-: the working-copy commit is usually empty, so you push its parent. There's also no git pull. You run jj git fetch, then jj rebase -o main to move your work onto the updated trunk.
You don't have to migrate
jj git init and jj git clone create a colocated repository, where .jj and .git share one working copy. Git sees a detached HEAD; Jujutsu syncs with Git on every command. You can use jj for an afternoon and still run git for the parts you haven't learned yet. Version 0.46.0 also added colocated secondary workspaces built on git worktree, which raised the minimum supported Git version to 2.42.0.
The honest caveats
Jujutsu is pre-1.0, and the README says so plainly: expect backward-incompatible on-disk format changes before 1.0.0, with transparent upgrades where possible. Git submodules aren't supported yet, and the project warns that workflows unlike the core developers' own may be rough.
None of that stops you from trying it. Clone a repository you don't care about, run jj log, and rewrite a commit you'd normally be afraid to touch. The first time jj undo saves you, the missing staging area stops looking like a loss.