Jujutsu vs Git
Jujutsu (jj) and Git compared for everyday version control: working-copy model, staging area, branches vs bookmarks, conflicts, undo, history rewriting, Git compatibility gaps, tooling and stability as of November 2026.
Quick Answer
Jujutsu is not a Git replacement on the server; it is a different command line on top of Git repositories. jj (v0.47.1, 5 Nov 2026, Apache-2.0, Rust) stores commits in a normal Git repo, works with GitHub, GitLab and any Git remote, and can live in the same folder as .git, so teammates never notice. What changes is the model: the working copy is itself a commit that is snapshotted automatically, there is no staging area, conflicts are recorded in commits instead of stopping a rebase, descendants are rebased automatically when you edit a commit, and an operation log gives you jj undo for any command. Git (2.56.0, 28 Sep 2026, GPL-2.0) remains the standard every tool, CI system and teammate understands, with full support for submodules, LFS, hooks, .gitattributes and worktrees, all of which jj's own compatibility page lists as unsupported. jj also still calls itself experimental and warns of breaking changes before 1.0. Switch to jj if you rewrite history a lot, juggle stacked changes, or keep losing work in rebases. Stay on Git if your repo depends on submodules, LFS or hooks, or your team needs one tool everybody knows.
Last updated November 5, 2026. Covers Jujutsu 0.47.1 (5 Nov 2026) and Git 2.56.0 (28 Sep 2026), using jj's docs (Git comparison, Git compatibility, FAQ, conflicts, operation log, working copy, GitHub, install), the jj README and 0.47.0 changelog, Git's 2.56 release notes and the BreakingChanges document for Git 3.0.
| Feature | Jujutsu | Git |
|---|---|---|
| Licence / Language | Apache-2.0, Rust | GPL-2.0 (v2 only), mainly C (Rust optional, mandatory planned for Git 3.0) |
| Maturity / Stability | Pre-1.0, self-described experimental; breaking changes possible before 1.0 | Stable 2.x series; Git 3.0 breaking changes documented, no release date |
| Storage Backend | Git repository (production-ready backend, uses gitoxide); colocated with .git by default | Native Git object store (SHA-1 default; SHA-256 planned default in 3.0) |
| Working Copy Model | Working copy is a commit, snapshotted automatically; new files auto-tracked | Working tree separate from commits; changes stay uncommitted until you commit |
| Staging Area | None (use jj split / jj squash -i) | Yes: the index (git add, add -p) |
| Branches | Anonymous heads by default; named bookmarks moved manually, map to Git branches | Current branch advances automatically on commit |
| Merge Conflicts | First-class: recorded in commits, operations never fail on conflicts | Stop the operation until resolved (--continue/--abort); rerere optional |
| Undo / Recovery | Operation log: jj undo, jj op revert, jj op restore | Per-ref reflog; reset/restore/revert |
| History Rewriting | Any commit editable; descendants auto-rebased; jj split, squash, rebase, arrange | git rebase -i, commit --amend, experimental git history (drop added in 2.56) |
| Remotes / Forges | Any Git remote via jj git fetch/push; jj git push -c creates a bookmark automatically | Native; the protocol every forge speaks |
| Submodules & Git LFS | Not supported (submodules ignored but preserved; no LFS) | Yes: submodules built in; LFS via the git-lfs extension |
| Hooks & .gitattributes | Not supported | Yes: client- and server-side hooks; .gitattributes |
| Multiple Working Copies | Native jj workspace (not git-worktree) | git worktree |
| Latest Release (Nov 2026) | v0.47.1 (5 Nov 2026) | 2.56.0 (28 Sep 2026) |
Jujutsu
A Git-compatible version control system written in Rust, started by Martin von Zweigbergk and now developed with help from several Googlers, whose CLI treats the working copy as a commit, records conflicts in commits and keeps an operation log that makes every command undoable.
Pros
- The working copy is an ordinary commit that is snapshotted automatically by almost every command, so there is no staging area to manage and uncommitted work cannot be lost to a bad checkout
- jj undo and the operation log record every repo change atomically, and jj op restore can return the whole repo, including bookmarks, to any earlier point
- Conflicts are stored in commits, so rebases and merges never stop halfway; there is no --continue dance, and you resolve conflicts whenever you choose
- Editing any commit automatically rebases all its descendants and moves bookmarks with them, which makes stacked changes and fixups cheap
- Uses a normal Git repository as storage, works with any Git remote, and can be colocated with .git so Git-based IDEs and tools keep working
- jj split, jj squash -i and jj rebase -r/-A/-B replace git add -p, commit --amend -p and most interactive-rebase use cases
Cons
- Officially experimental: the README warns of workflow gaps and of backward-incompatible on-disk format changes before 1.0, and 0.47.0 alone lists several breaking changes
- No support for Git submodules, Git LFS, hooks, .gitattributes, partial clones or git-worktree, and only lightweight tags can be created
- A new mental model for teams: no current branch, bookmarks you move by hand, and auto-tracked files that need ignore rules set up early
- Interleaving git and jj commands in a colocated repo can create confusing bookmark conflicts or divergent changes, per jj's own FAQ
- Much smaller ecosystem of GUIs, IDE integrations and documentation than Git, and the CLI and jj-lib API are not stable
Best For
Developers who rewrite history often, maintain stacks of dependent changes for review, or want painless undo, and who work in repos without submodules, LFS or hook-heavy setups.
Git
The distributed version control system created for Linux kernel development and used by virtually every forge, CI system and IDE, with an index (staging area), branch-based workflow and a large set of plumbing and porcelain commands.
Pros
- Universal standard: every forge, CI service, IDE, deploy tool and teammate understands it, and it is installed nearly everywhere
- Complete feature set that jj lacks today: submodules, Git LFS, hooks, .gitattributes, worktrees, partial and shallow clones, annotated tags
- Mature and stable: 2.x releases keep backward compatibility, and planned breaking changes are documented in advance for a future Git 3.0
- The staging area allows precise, hunk-by-hunk commit construction for people who like to curate commits before making them
- Huge body of documentation, including the free Pro Git book, plus GUIs, TUIs and answers to almost any error message
- Still improving: 2.56.0 extended the git refs toolbox and taught the experimental git history command a drop subcommand
Cons
- The index, multiple reset modes and detached HEAD are a steep learning curve that jj removes entirely
- Merge and rebase conflicts stop the operation and require --continue, --abort or --skip; resolutions are not carried through later rebases without rerere
- Rewriting an older commit in a stack means interactive rebase and manually updating dependent branches
- Recovery relies on per-ref reflogs; there is no single undo for an arbitrary command
- Uncommitted changes can be lost to a careless checkout, reset --hard or stash mishap
Best For
Every team by default, and especially repos that use submodules, LFS, hooks or .gitattributes, mixed-skill teams, and anyone who needs maximum tool compatibility and stability.
The core model: working-copy commit, no index, no current branch
Jujutsu's Git comparison lists the differences that matter day to day. First, the working copy is automatically committed. Almost every jj command snapshots your files into the working-copy commit, so there is no separate uncommitted state and no stash. New files are tracked automatically unless an ignore rule or the snapshot.auto-track setting excludes them, which is why jj's docs tell you to set up .gitignore early. Second, there is no index. The docs argue that Git's staging area is really an intermediate commit between HEAD and the working tree, and jj models it with real commits instead. git add -p followed by git commit becomes jj split -i, or the near-identical jj commit -i, and amending part of your changes into the parent becomes jj squash -i. Third, there is no current branch. Detached HEAD is jj's normal state, every visible head is kept so commits are never garbage-collected out from under you, and named branches exist as bookmarks that you move explicitly. Git users trip over this most, because a bookmark does not follow new commits the way a Git branch does. jj's FAQ opens with exactly that question. Git's model is the reverse: the working tree, the index and HEAD are three separate states, and learning what each flavour of git reset touches is a rite of passage.
Conflicts, rebasing and undo
The biggest practical gain from jj shows up when history gets messy. In Git, a rebase or merge that hits a conflict stops. You fix the files, then run --continue, or abort and start again. Resolutions are not remembered unless rerere is enabled. In jj, conflicts are first-class: a rebase that conflicts still succeeds and records a logical representation of the conflict in the commit, not just markers in a file. You resolve it later by checking out the commit with jj new, editing the markers, and squashing the fix back. Descendants of any rewritten commit are rebased automatically and bookmarks follow them, so fixing a typo three commits down a stack is a single command rather than an interactive rebase plus manual branch updates. jj also says this lets it rebase merge commits correctly, including conflict resolutions done inside a merge, which removes the main reason for so-called evil merges. Recovery is the other half. Every jj command is recorded in an operation log containing a snapshot of all bookmarks, heads and working-copy commits. jj undo reverses the last operation, jj op revert undoes an older one, and jj op restore rewinds the whole repo. Git's reflog records history per ref, which is enough for experts but far less forgiving. The operation log also allows lock-free concurrency, even across machines on a shared file system.
Git compatibility: what works and what does not
jj's production-ready backend is a normal Git repository, using the gitoxide Rust library, and jj's docs say you can collaborate with Git users without them knowing. By default jj git init and jj git clone create a colocated workspace with both .jj and .git at the top level, so IDEs, build tools and git commands keep working. jj imports and exports Git state on every command. Remote operations run through git under the hood, so your existing SSH keys and credential helpers apply. Fetching and pushing go through jj git fetch and jj git push, and jj git push -c @- pushes a change under an auto-generated bookmark such as push-mwmpwkwknuz, which makes one-change pull requests quick. The compatibility page is just as clear about the gaps. Submodules, Git LFS, hooks, .gitattributes, partial clones and git-worktree are not supported. Only lightweight tags can be created, shallow clones cannot be deepened, and jj respects only a few settings from ~/.gitconfig, such as remotes and core.excludesFile. jj offers native workspaces and sparse checkouts instead of worktrees. The FAQ also warns that interleaving git and jj mutations in one colocated repo can produce bookmark conflicts or divergent changes, and that Git tools may misread conflicted commits. If your repo depends on any of the unsupported features, jj is not ready for it.
Maturity, releases and what is coming in Git 3.0
The projects are at very different stages. jj releases roughly monthly: 0.45.0 on 3 September, 0.46.0 on 7 October, 0.47.0 on 4 November and 0.47.1 on 5 November 2026, the last one fixing a dependency error that broke Linux builds. The README calls Jujutsu an experimental version control system. It says Git compatibility is stable and most developers use it daily, but warns of work-in-progress features, suboptimal UX and backward-incompatible on-disk format changes before 1.0. The 0.47.0 changelog shows what that means in practice: Timestamp.format() moved to jiff's strftime syntax, non-colocated workspaces stopped updating remote-tracking Git refs on fetch and push, and template methods changed type. jj is open source under Apache-2.0. Google is a major contributor, but the README says it is not a supported Google product. Git 2.56.0 shipped on 28 September 2026 with incremental changes: new git refs subcommands, a drop subcommand for the experimental git history command, better git log --follow on non-linear history, and typo advice for commands such as git push origin/main. Git's BreakingChanges document lists what Git 3.0 will change, with no release date yet: SHA-256 as the default hash for new repositories, reftable as the default ref storage, main as the default branch name, and Rust as a mandatory build dependency.
Adopting jj on a Git team
Because jj writes standard Git commits, adoption can be personal and reversible. Install it with Homebrew (brew install jj), pacman, zypper, Nix, cargo binstall or a prebuilt binary. Pre-built binaries exist for Windows, macOS and Linux, and building from source needs Rust 1.97.1 or newer. Then run jj git init inside an existing checkout. The Git repo becomes jj's backing store, and you can still type git commands whenever jj does not cover something. Reviewers on GitHub or GitLab see normal branches and commits. Expect a few habits to break. Bookmarks do not advance on their own, so you create or move one before pushing, or let jj git push -c generate it. Large untracked files get snapshotted unless they are ignored. Pre-commit hooks will not run from jj, so linting has to move to CI or an explicit command. jj's FAQ even has an entry for Vite and Vitest projects whose file watchers react to jj's snapshot activity. Tooling that parses jj output should expect changes, because neither the CLI nor jj-lib is a stable API. The return is that stacked changes, fixups and conflict-heavy rebases, the work Git makes most error-prone, become routine. Teams that want everyone on one tool should standardise on Git and let individuals use jj on top.
Verdict
For most teams, Git stays the system of record. Jujutsu is a better command line for the person at the keyboard, and because it writes ordinary Git commits to an ordinary Git repo, you can adopt it alone without asking anyone. That is the real recommendation. If you spend time on interactive rebases, stacked pull requests, fixups to older commits or recovering from botched merges, install jj and run jj git init in an existing checkout. Automatic rebasing of descendants, conflicts that do not block, and jj undo for any command remove most of the pain, and you can drop back to git commands in the same colocated folder whenever jj lacks something. Do not switch, or keep jj to personal use, if the repository relies on submodules, Git LFS, client-side hooks such as pre-commit, or .gitattributes, since jj's compatibility page lists all of these as unsupported. The same goes if you need a tool whose behaviour will not change under you: jj is pre-1.0, calls itself experimental, and still ships breaking changes, as 0.47.0 did. New developers should still learn Git first. It is what every job, CI pipeline and tutorial assumes, and jj's concepts make more sense once you know what problem they solve.