Using Jujutsu in a colocated git repository
Jujutsu (jj
) is a Git-compatible version control system that offers a different approach to managing your code history.
I have spent the last few weeks using Jujutsu (or jj
) daily on personal and work git repositories.
One of its advantages is that you can use it locally alongside your team without them being aware that you’re managing your code history differently.
Really, Jujutsu is a frontend for git, using git as its backend. Your work is still based on a commit history, but the way you evolve your commits is different.
In this post, we’ll explore how to use Jujutsu alongside an existing Git repository.
Setting Up Jujutsu with an Existing Git Repository
Cloning the repository
We will be working with an existing repository. I’ll be using https://github.com/maiku1008/jj-demo as an example. Feel free to fork it or create a new repository.
Let’s start with cloning it:
|
|
This is how the directory tree looks:
|
|
Initializing Jujutsu
Use the following command to initialize Jujutsu in the git repository:
|
|
This creates a .jj/
directory at the root of the project, which is ignored by git by default.
As mentioned before, Jujutsu uses git
as a backend.
We can now inspect the repository:
|
|
This shows us the working copy commit (where our changes will go) and its parent commit. Unlike Git, Jujutsu always has a working copy commit.
Every time a change is made, the equivalent of a git commit --amend
is made to save that change.
If you’re following along with this how-to, note that the ID hashes shown here will be different from the ones you will have locally.
Basic Jujutsu Workflows
Creating and Managing Commits
Let’s make some changes to our code and see how Jujutsu handles them:
|
|
Our working copy (with the change ID ppmklykz
) has some changes but has no description.
Let’s fix that:
|
|
Note how the change ID ppmklykz
of our working copy stayed the same, but the actual commit ID has changed.
Now let’s create a new commit:
|
|
Jujutsu creates a new change ID and commit ID, and automatically moves our working copy forward. Let’s make another change:
|
|
Let’s squash the changes:
|
|
This will open our default editor to allow us to edit our desired commit message:
|
|
Let’s change the commit message to “add comments to main.rs”
|
|
Once we exit the editor, we will be presented with the new state:
|
|
This combines the changes from both commits into a single commit.
Working with Branches and Bookmarks
In Jujutsu, bookmarks map to actual branches in Git:
|
|
By default the new bookmark is pointing to our working copy
Let’s set our current working copy to our ppmklykz
change.
|
|
Let’s create a new bookmark
|
|
To see all bookmarks:
|
|
Synchronizing with Remote Repositories
Pushing Changes
To push your changes in the current working copy to the remote Git repository:
|
|
Jujutsu automatically maps your bookmarks to Git branches when pushing.
To push a specific bookmark:
|
|
Fetching and Tracking Remote Changes
To fetch changes from the remote repository:
|
|
To track a remote branch:
|
|
To update your local repository with remote changes:
|
|
To see what changes came in from the remote:
|
|
Wrapping up
Hopefully this short guide provides a clear introduction to using Jujutsu in an existing repository without disrupting your teammates’ workflow.
I believe this is the most common use case for most developers, yet as of March 2025, straightforward documentation on this specific scenario remains surprisingly scarce. I hope you’ve found this helpful for your own version control journey with Jujutsu!