Jujutsu

Jujutsu (jj) is a version control system built to work alongside or instead of Git, using Git repositories as its default storage backend. It's aimed at developers who like Git's ecosystem but want a cleaner model underneath: no staging area, automatic commit amending, and built-in undo. Both newcomers to VCS and experienced Git users working on large codebases are the target audience.

Under the hood, jj separates its user interface and versioning logic from the storage layer. Right now the Git backend is the only production-ready option, which means you can clone, fetch, and push to any existing Git remote, and the commits jj creates look like normal Git commits to anyone else on the project. You can even run jj and git side by side in a colocated workspace.

Key features

• Working-copy-as-a-commit: file changes are snapshotted automatically into a real commit, so there's no index, staging area, or git stash needed.
• Operation log with undo: every operation against the repo (commit, pull, push, rebase) is recorded with a snapshot of repo state, so you can undo or revert any past operation, not just the last one.
• Automatic rebase: modifying a commit automatically rebases all its descendants on top, updating bookmarks and the working copy as needed.
• First-class conflicts: conflicts are stored as part of the commit data rather than blocking an operation, so commands like rebase never get interrupted, and conflict resolutions propagate to descendant commits automatically.
• History rewriting toolkit: commands like jj describe, jj diffedit, jj split, and jj squash -i let you edit, split, or move changes between commits without checking them out first.
• Anonymous branches: like Mercurial, you don't need to name a branch for every small change.
• Concurrent-safe repository storage (experimental): designed so that syncing a repo via Dropbox, rsync, or similar tools shouldn't corrupt it, even under concurrent access, though this feature is still experimental.
• Git compatibility: uses the gitoxide Rust library for its Git backend, letting you interoperate with any Git remote or forge.

Ideal use cases

jj fits developers who want Git's networking and hosting ecosystem but a less error-prone local workflow, especially for patch-based or history-rewriting-heavy work like stacked diffs, rebasing chains of commits, or frequently amending in-progress changes. Teams already on GitHub or another Git forge can adopt jj individually without forcing collaborators to switch, since pushed commits remain ordinary Git commits.

It's a good match for anyone who finds themselves fighting git stash, merge conflicts during rebase, or losing track of what a series of git reflog entries actually did. The operation log and undo model make it easier to recover from mistakes, including ones a teammate made in a shared repo.

It's not yet a good fit for projects relying on Git submodules, since that support isn't complete. Teams with email-based patch workflows (e.g., mailing-list-driven contribution models) also aren't well supported. Given its experimental status, some workflows and edge cases outside what the core jj developers use daily may hit rough edges, performance bugs, or UX gaps, so risk-averse production teams should evaluate carefully before making it their sole VCS.

Installation

The README points to the official installation and setup guide at docs.jj-vcs.dev rather than embedding install commands directly. In general terms, since jj is written in Rust, you can build it from source with Cargo if a prebuilt binary isn't available for your platform:

cargo install --locked jj-cli

After installing, initialize jj in an existing Git repo to try it out:

jj git init --colocate

This sets up jj alongside your existing .git directory so both jj and git commands work interchangeably. From there, the project recommends working through the official tutorial and the Git-comparison doc, which maps common git commands to their jj equivalents. The jj help and jj help -k <keyword> commands are also useful references once installed.