Jujutsu (jj)

A new front-end for your existing Git repos. Built at Google. Same .git folder, same remotes, your teammates don't have to switch — but the model under your hands is radically different. Whether that's a gift or a tax depends on how much you rewrite history.

The rebase race

You forked 3 commits off main. Someone landed 3 more commits to main while you were working, and two of yours will conflict with the new tip. Hit play on both.

Note the difference in stops. Git halts the operation on each conflict; you must resolve --continue before any other work. jj stores the conflict inside the commit and keeps going — you can leave it conflicted overnight if you want, and rebase or branch off it in the meantime.

The five mental-model shifts

If you only learn five things, learn these. Everything else in jj falls out of them.

The working copy, visualized

Git's three-state model vs jj's one-state model. Click "Edit file" and walk through what each tool needs from you to durably capture that edit.

Steps to common tasks

How many discrete commands each tool needs for typical history-shaping work. Bars scroll into view and fill on first sight.

Same task, both tools

Pick a workflow. The git column is what most teams actually type; the jj column is the same intent expressed in jj's primitives.

# find the commit, mark for fixup
git log --oneline
# edit files...
git add -p
git commit --fixup=abc123
git rebase -i --autosquash main
# resolve any conflicts, --continue x3

# edit files, then:
jj squash --into abc123
# descendants auto-rebase
# if conflict: keep working, fix later

git rebase -i HEAD~3
# mark commit as 'edit'
git reset HEAD^
git add -p   # pick hunks for first half
git commit -m "first half"
git add .
git commit -m "second half"
git rebase --continue

jj split -r abc123
# interactive diff editor opens
# pick what goes in the first commit
# rest stays in the second

git checkout main && git pull
git checkout feature-3
git rebase main
# conflict! resolve, --continue
git checkout feature-4
git rebase feature-3
# conflict! resolve, --continue
git checkout feature-5
git rebase feature-4
# ... and so on

jj git fetch
jj rebase -d main
# whole stack moves at once
# conflicts (if any) committed
# in-place; keep working or fix now

git reflog
# scroll, find the pre-rebase SHA
git reset --hard HEAD@{12}
# hope you picked the right one
# now do the same for every branch
# that the rebase moved

jj undo
# done. all refs restored atomically.

Cheat sheet

When not to use jj

The honest part. jj is pre-1.0, the CLI is still evolving, and entire ecosystems (GUIs, hooks, hosted-service integrations) assume git. Here's where the friction outweighs the wins.

So, should I switch?

The tl;dr: jj isn't "git but better" in the abstract — it's git but better for the specific workflows where git is worst. If those workflows are your daily life, the upgrade is dramatic. If they aren't, you'll learn a new tool to do the same thing.