Version control systems (VCS) are the silent enablers of every successful software delivery pipeline. For over 15 years, Git has reigned supreme as the de facto standard for tracking changes in code. However, as development workflows become increasingly complex, some limitations of Git have become apparent thus sparking interest in newer, more ergonomic alternatives.
Enter Jujutsu (often abbreviated as "jj"), a Git-compatible version control system designed to simplify common tasks, improve collaboration, and reduce the risk of costly errors.
This blog explores how Jujutsu compares to Git, why it’s gaining interest among forward-looking teams, and what makes it a strong contender in modern DevOps environments.
But first, let’s take a step back.
To understand Jujutsu’s value, it helps to revisit what makes Git so powerful and which are the areas where it falls short.
- About Git
- Key Git concepts
- What is Jujutsu?
- Why Jujutsu?
- Key features that set Jujutsu apart
- Git and Jujutsu: At a glance
- Workflow comparisons
- Feature branch workflow
- Stashing workflow
- History editing workflow
- Code review workflow
- Cherry-picking workflow
- Bisecting Workflow
- Collaborative Workflow with Multiple Contributors
- Getting started with Jujutsu
- Installation
- Configuration
- Basic Commands
- Migration Tips
- Use Cases
- Final thoughts
About Git
Git is a distributed version control system created by Linus Torvalds in 2005 for Linux kernel development. Today, it powers nearly every modern software project, with platforms like GitHub, GitLab, and Bitbucket built around it.
Key Git concepts
- Distributed architecture: Each developer has a complete copy of the entire repository history.
- Branching and merging: Lightweight branches enable parallel development and integration.
- Staging area: Acts as an intermediate zone between working directory and commit history.
- Commit hashes: Unique identifiers for each commit using SHA-1 hashing.
- Remote repositories: Central repositories that facilitate collaboration.
While Git is powerful, its design has some notable drawbacks, especially as workflows scale in complexity. A steep learning curve, uncommitted changes, rebase complexity, history rewriting and merge conflicts are among the prominent challenges that developers encounter.
What is Jujutsu?
Jujutsu is a Git-compatible VCS designed to overcome Git’s shortcomings, particularly around user experience, mutability, and conflict resolution. It aims to make daily workflows simpler and less error-prone, while remaining compatible with existing Git tooling.
Most importantly, Jujutsu is not a replacement for Git but rather an alternative interface to Git repositories, allowing teams to adopt it incrementally without disrupting their existing workflows.
What Jujutsu primarily brings to the table is:
- Git compatibility
- Simplified mental model
- Improved workflows
- Flexible history editing
- Better collaboration
Why Jujutsu?
While Git’s design is brilliant, it’s not always developer friendly. Its steep learning curve, verbose commands, and history manipulation quirks often lead to frustration, especially in fast-paced environments.
- Git’s power often comes at the cost of usability. Developers frequently run into issues like: Cryptic command-line interface (CLI)
- Confusing concepts like detached HEAD, index/staging area
- Complex rebasing and merging mechanisms
- Fragile conflict resolution process
Jujutsu was created by a Googler as an attempt to modernize version control. The philosophy behind Jujutsu is:
- Make the user interface more intuitive
- Allow safer, less error-prone versioning
- Provide better conflict handling
- Support mutable history for easier correction and clean-up
In short, Jujutsu is what Git could be if designed with today’s developer experience in mind - smarter, safer, and more human-centric.
Key features that set Jujutsu apart
- Immutable history model: Every operation creates a new commit, reducing risk and making history easier to understand.
- Revsets: a powerful query language for selecting commits. This feature allows developers to perform complex operations on specific sets of commits easily.
# Find all commits authored by Alice that touch Python files
jj log -r "author(alice) & file(*.py)" - Working copy as a commit: In Jujutsu, the working copy is treated as a special commit, allowing all operations that work on commits to also work on the working copy. This unifies the conceptual model and simplifies many workflows.
- Multi-layered branches: Separates local, remote, and collaborative branches for clarity.
- Operation log: Easy ‘undo’ actions and review workflow history.
- Simplified Conflict Resolution: Improved tools to manage and resolve complex conflicts including better visual indications and automatic resolutions.
- Git-Compatible: Works seamlessly with existing Git repositories.
Git and Jujutsu: At a glance
Working copy
Workflow comparisons
Let us compare some common Git workflows with their Jujutsu equivalents to highlight the differences and benefits.
Feature branch workflow
Git:
# Create and switch to a new feature branch
git checkout -b feature/new-feature
# Make changes and commit
git add .
git commit -m "Implement new feature"
# Push to remote
git push -u origin feature/new-feature
# Update with main branch changes
git checkout main
git pull
git checkout feature/new-feature
git rebase main
# Resolve conflicts if any
git add .
git rebase --continue
# Force push after rebase
git push --force-with-lease
Jujutsu:
[bash]
# Create a new change with description
jj new -m "Implement new feature"
# Create a branch pointing to this change
jj branch create feature/new-feature
# Make changes (they are automatically tracked)
# Update the current change description if needed
jj describe -m "Implement new feature - updated"
# Push to remote
jj git push --branch feature/new-feature
# Update with main branch changes
jj rebase -d main
# Resolve conflicts if any and continue
jj resolve
# Push updated branch
jj git push --branch feature/new-feature
Advantage Jujutsu:
- No need to explicitly stage changes before committing
- Rebasing is simpler and safer
- No need for force pushes
- Conflict resolution is more streamlined
Stashing workflow
Git:
[bash]
# Save uncommitted changes
git stash push -m "Work in progress"
# Switch branches
git checkout another-branch
# Do some work and commit
git add .
git commit -m "Work on another branch"
# Return to original branch
git checkout original-branch
# Apply stashed changes
git stash pop
Jujutsu:
[bash]
# Working copy is already a commit - create a new change
jj new -m "Work in progress"
# Switch to another branch
jj new main -m "Work on another branch"
# Do some work (changes are automatically tracked)
# Return to previous work
jj edit @-- # Edit the previous change
# Or checkout a specific change by ID
jj checkout <change-id>
Advantage Jujutsu:
- No need for a separate stash mechanism
- Working copy changes are always preserved
- Easier to manage multiple sets of changes
History editing workflow
Git:
[bash]
# Interactive rebase to edit history
git rebase -i HEAD~3
# In the editor, mark commits to edit with 'edit'
# For each commit marked as 'edit':
git commit --amend
git rebase --continue
# To reorder commits, change the order in the interactive editor
# Then continue the rebase
git rebase --continue
Jujutsu:
[bash]
# Edit a specific commit (3 commits back)
jj edit @---
# Make changes to files
# Update the commit
jj amend
# Return to the latest change
jj edit @
# Reorder commits using rebase
jj rebase -r @-- -d @--- # Move second-to-last commit after third-to-last
Benefits of Jujutsu:
- More intuitive history editing
- Less manual intervention required
- Safer operations with lower risk of mistakes
Code review workflow
Git:
[bash]
# Create a branch for review feedback
git checkout feature-branch
git checkout -b address-feedback
# Make changes based on feedback
git add .
git commit -m "Address feedback"
# Squash commits for clean history
git rebase -i HEAD~2
# In editor, change 'pick' to 'squash' for commits to combine
# Push updated branch
git push --force-with-lease origin feature-branch
Jujutsu:
[bash]
# Make changes based on review feedback
# (assuming you're on the feature branch)
jj describe -m "Address review feedback"
# Make the changes to files
# Amend the current change
jj amend
# To squash with previous commit
jj squash
# Push updated branch
jj git push --branch feature-branch
Advantage Jujutsu:
- Simpler commands for common operations
- Better visualization of history changes
- More intuitive squashing of commits
Cherry-picking workflow
Git:
[bash]
# Identify commit to cherry-pick
git log --oneline
# Switch to target branch
git checkout target-branch
# Cherry-pick the commit
git cherry-pick abc123def
# If conflicts occur
git add .
git cherry-pick --continue
# Push changes
git push origin target-branch
Jujutsu:
[bash]
# Identify commit to cherry-pick
jj log
# Switch to target branch
jj checkout target-branch
# Duplicate the commit (cherry-pick equivalent)
jj duplicate abc123def
# If conflicts occur, resolve them
jj resolve
# Push changes
jj git push --branch target-branch
Advantage Jujutsu:
- More intuitive representation of cherry-picked commits
- Better conflict resolution for cherry-picks
- Explicit indication that a commit is cherry-picked
Bisecting Workflow
Git:
[bash]
# Start bisect process
git bisect start
# Mark current commit as bad
git bisect bad
# Mark a known good commit
git bisect good abc123def
# Git automatically checks out commits for testing
# After testing each commit:
git bisect good # if the commit is good
# or
git bisect bad # if the commit is bad
# After finding the faulty commit
git bisect reset
Jujutsu:
[bash]
# List commits in the range to bisect
jj log -r "abc123def..@"
# Create a new workspace for testing
jj workspace add ../bisect-workspace
# Switch to the workspace and test different commits
cd ../bisect-workspace
jj edit <commit-to-test>
# Test the commit, then try another
jj edit <another-commit-to-test>
# After finding the faulty commit, clean up
cd ../original-workspace
jj workspace forget ../bisect-workspace
Benefits of Jujutsu:
- Multiple workspaces allow parallel testing
- No need to constantly switch working copies
- Better visualization of the bisect process
Collaborative Workflow with Multiple Contributors
Git:
[bash]
# Get latest changes from remote
git fetch origin
# See what others have done
git log --oneline origin/main..HEAD
# See incoming changes
git log --oneline HEAD..origin/main
# Integrate others' changes
git rebase origin/main
# If conflicts occur during rebase
git add .
git rebase --continue
# Incorporate specific changes from a colleague
git cherry-pick <colleague-commit-hash>
# Push your changes
git push origin main
Jujutsu:
[bash]
# Get latest changes
jj git fetch
# See what's new on remote
jj log -r "remote_branches()"
# See your local changes vs remote
jj log -r "main..@"
# Integrate remote changes
jj rebase -d main@origin
# If conflicts occur
jj resolve
# Duplicate specific changes from a colleague
jj duplicate <colleague-commit-id>
# Push your changes
jj git push --branch main
-
Advantage Jujutsu:
- Better visibility of remote changes
- Simplified integration of others' work
- More intuitive handling of distributed workflows
Getting started with Jujutsu
Installation is simple (via Homebrew, winget, or source), and setup involves minimal configuration. Its command set is intuitive for Git users - just without the baggage of staging, complex rebasing, or stash juggling.
Here is some practical guidance on installation, configuration, and command equivalents for those ready to explore.
Installation
macOS
[bash]
brew install jj
Windows
[cmd]
winget install jujutsu --id jj-vcs.jj
From Source
[bash]
git clone https://github.com/martinvonz/jj.git
cd jj
cargo install --path .
Refer official install and setup guide
Configuration
Create a .jjconfig.toml file in your home directory:
toml:
[user]
name = "Your Name"
email = "your.email@example.com"
[ui]
diff-editor = "vscode"
merge-tool = "vscode"
[aliases]
st = "status"
co = "checkout"
Basic Commands
[bash]
# Initialize a new repository
jj init
# Or clone an existing Git repository
jj git clone https://github.com/example/repo.git
# Create a new change
jj new -m "Add new feature"
# Modify the current change
jj amend
# View status
jj status
# View history
jj log
# Compare changes
jj diff
# Push to Git remote
jj git push
Migration Tips
For Git users transitioning to Jujutsu, here are some helpful equivalents:
Use Cases
Large-scale Monorepos
Companies with large monorepos face unique challenges with version control. Jujutsu offers several advantages:
- Better performance with efficient handling of large repositories
- Improved visibility with clearer history visualization
- Enhanced collaboration with better merge conflict resolution
- Simplified workflows with reduction in complex Git commands
Cross-team collaboration
Enterprises with multiple teams working on shared codebases benefit from:
- Flexible branching: Easier management of feature branches
- Improved merge processes: Better resolution of conflicts
- Enhanced history editing: Cleaner commit history
- Compatibility with existing workflows: Incremental adoption possible
Known Challenges with Jujutsu
Despite its promise, Jujutsu is still evolving. Limitations include:
- A smaller ecosystem compared to GitHub/GitLab.
- Differences in terminology and workflows require mental re-mapping.
- Limited IDE integrations.
- A learning curve for experienced Git users due to different mental models.
- Less community maturity compared to Git.
That said, its strong Git interoperability allows teams to experiment and gradually adopt features at their own pace.
Final thoughts
Jujutsu represents a significant evolution in version control systems, addressing many of Git's limitations while maintaining compatibility with Git repositories. While Git remains the dominant VCS and will continue to be widely used, Jujutsu offers a compelling alternative that simplifies many common workflows and reduces friction in the development process. As more developers experience these benefits, we may see a gradual shift toward Jujutsu or similar systems that build upon Git's foundation while addressing its pain points.
For teams considering Jujutsu, the good news is that adoption can be incremental. Developers can start using Jujutsu alongside Git on the same repositories, allowing for a gradual transition that minimizes disruption while maximizing benefits.
Whether you're a seasoned Git user looking for a more intuitive experience or a team leader seeking to improve developer productivity, Jujutsu is worth exploring as the next evolution in version control systems.
At InfoVision, we're constantly exploring such next-gen developer tools to improve engineering efficiency and software quality. If you're rethinking your DevOps strategy or looking to modernize your toolchain - let’s talk.
We’d be happy to share insights, adoption strategies, or even help you pilot emerging technologies like Jujutsu in your environment.
Connect with us at digital@infovision.com