A Git-compatible VCS with a commit-centric workflow

Jujutsu (jj) is a version control system written in Rust that aims to be both simple and powerful while staying compatible with Git. It is a 'commit-centric' tool: instead of building workflows around branches and staging areas, it treats every snapshot of the working copy as a commit object, making history manipulation and collaboration more direct. With over 31k GitHub stars and an Apache-2.0 license, it is a popular alternative for developers who want a fresh take on version control without leaving the Git ecosystem.

Traditional Git workflows are powerful but notoriously complex. The three-way split between working directory, index (staging area), and commit constantly trips up newcomers, and operations like rebase or amend often require careful sequencing to avoid losing work. Jujutsu removes the index entirely and models the working copy as part of the commit graph. This means you can create, reorder, squash, or split commits without the mental overhead of a separate staging area. The repository also ships a dedicated docs/conflicts.md and demos for juggling conflicts, showing that conflict resolution is treated as a first-class concern rather than an edge case.

The heart of Jujutsu is the commit-centric workflow. Every change is a commit, and commits are immutable except for explicit rewriting operations. This uniform model collapses the distinction between branches, tags, and the working copy – they are all just references to commits. The design also embraces an operation log: every action you run is recorded as an operation, which means you can inspect the history of your own work and undo anything. The repo includes demos/demo_operation_log.sh and demos/operation_log.svg to illustrate this capability.

Jujutsu treats conflicts as normal, inspectable states instead of blocking events. When a merge or rebase results in a conflict, jj records it inside the commit graph and lets you continue working; you can resolve different parts of the conflict incrementally. This is complemented by the working-copy model: the working copy is itself a special commit, so editing files is always part of a versioned context. The demos named demo_resolve_conflicts.sh and demo_working_copy.sh show these behaviors, and the docs/conflicts.md file goes into detail.

The repository is split into two main Rust crates: core/ contains the engine, while cli/ holds the command-line interface on top of it. This separation keeps the fundamental algorithms testable and reusable. The docs/design/ directory hosts design documents, and the demos/ folder provides reproducible shell scripts plus generated SVG diagrams for each major workflow. Build files such as default.nix, deny.toml, and a CI setup under .github/workflows/ indicate a mature open-source project with attention to reproducibility and quality.

The fastest way to evaluate jj is to install it using your platform’s package manager, following the instructions at https://jj-vcs.dev. Once installed, you can either initialize a new repository with the jj command or work against an existing Git repository, thanks to the built-in Git compatibility. The repository contains docs/cli-reference.md with the full command list and demos/ with narrated scripts that show the main flows step by step. Start with demo_git_compat.sh to see how jj coexists with Git.

Jujutsu is a great fit for developers and teams who want a more uniform and undoable workflow while keeping interoperability with existing Git remotes and hosting platforms. Because it is still evolving, you should expect occasional command or output changes; the project maintains a changelog (CHANGELOG.md) and community docs. If you rely heavily on Git internals or niche extensions, verify that the feature you need is supported. For most day-to-day work, jj’s commit-centric model and safety nets – operation log and first-class conflicts – offer a compelling, lower-stress alternative to Git.