Does Jujutsu Work with GitHub? Why the Name? 7 Questions Answered

Q1. Can I Use Jujutsu with My Existing Git Repositories?

Yes. Jujutsu is highly compatible with Git, and running jj git init inside an existing Git repository is all it takes to start using Jujutsu there. You have nothing to lose by trying it, and you don’t have to give up Git.

Jujutsu’s storage layer is pluggable, and Git is the default backend¹. The Git backend stores commits as ordinary Git objects, so the history you create with Jujutsu can also be accessed through Git tools.

A repository where Jujutsu and Git live side by side is called colocated. You used to have to pass the --colocate option to jj git init, or to jj git clone when copying a remote repository, to get one. Since v0.34.0, released in October 2025, colocated is the default. You’ll still see --colocate in older articles, but you can safely skip it now.

In a colocated repository, a .jj/ directory sits next to .git/ at the root. The .gitignore inside .jj/ contains /*, so adding Jujutsu doesn’t touch your root .gitignore. As mentioned above, your Git commit history keeps getting updated while you use Jujutsu, and you can push it to GitHub or any other remote as usual. Signed commits are supported too, so it works in repositories that require them. In other words, if you want to, you can be the only person on a Git team who uses Jujutsu.

Git commands also keep working in a colocated repository. And if you decide Jujutsu isn’t for you, you can switch back to Git by deleting the .jj/ directory. Jujutsu leaves your existing Git setup as it is, which makes it about as cheap to try as a tool can be.

Q2. What Can Git Do That Jujutsu Can’t?

For all its Git compatibility, Jujutsu still doesn’t support some Git features, even in v0.46.0, the latest release as of October 2026. Three of them are the most likely to cause trouble in real projects:

• Submodules
• LFS (Large File Storage)
• Git hooks or a direct equivalent

The most serious of these is probably the lack of submodule support. Git submodules let you embed another independent Git repository as a subdirectory, usually to share code between projects.

Lack of support doesn’t mean your submodule contents get lost. The problem is that they don’t follow you when you move through history. With jj edit, you can jump to any point in history like a time machine and view or edit files there, but submodule directories stay as they were. You have to run git submodule update --recursive by hand every time.

Jujutsu also ignores changes you make inside a submodule, so recording them in history means running git add and git commit yourself. You can still work in a repository that has submodules, but you need to understand the limitations and handle the unsupported operations manually.

On the development side, submodules don’t fit well with Jujutsu’s data model, and supporting them would require major design changes, which is a big reason support has lagged. It’s on the roadmap, but much of the design documentation is still unfinished, and there’s no implementation timeline in sight². These days, teams that need to share code often choose a monorepo or private packages on something like GitHub Packages instead of submodules. If you get to make that call, it’s worth considering those options for new projects.

Git LFS is a Git extension for video, audio, large binaries, and other big files. It stores the large data outside the repository and keeps only pointers to it in Git. On GitHub, Git LFS is currently the only way to manage files over 100 MB in a repository³.

It’s widely used in fields like game development, and it isn’t supported either. Work is underway, with several PRs already submitted⁴, but some design questions remain unresolved, including ones that affect other features. There’s still no clear timeline for a release.

Finally, Git hooks. Hooks run your own scripts in response to specific Git actions, and far more teams rely on them than on the other two features. Typical uses are running formatters and linters before a commit, or tests and security audits before a push. Husky with lint-staged, and Lefthook, are the popular tools here.

Jujutsu commands never trigger Git hooks. jj git push, for example, calls git push internally, but passes --no-verify to deliberately skip hooks⁵. Officially, there’s no way to trigger Git hooks at a time of your choosing, and no Jujutsu-native hook mechanism either.

The reason is that hooks don’t match Jujutsu’s core design and data model. A couple of factors stand out:

• Jujutsu automatically commits your file changes as you work, so there’s no explicit commit step that hooks can run before.
• Jujutsu rewrites code without going through your working directory, for example when you squash or when editing an old commit automatically rebases its descendants. Passing tests at the first commit doesn’t guarantee anything later on.

While they don’t cover everything Git hooks can do, Jujutsu does offer a few official tools that fit its model. With jj fix, you register formatters in your config, and running it walks back through your mutable history and formats the files changed in each commit. jj run executes an external command against a single commit or a range of commits. You can use it to run builds or tests across your history, and since it writes any file changes the command makes back into the target commits, it also works for autofixing linters or other code-fixing tools.

So what if your team has an elaborate hook setup built around Git and you want to be the only one using Jujutsu? There are several approaches depending on the situation, and the topic could easily fill an article or two, so I’ll skip it here. If you’re curious, my book Juju-chu! Starting Your Jujutsu×AI Workflow with `jj new` covers this in section 4-3, “Alternative Tactics for Git Hooks.”

Q3. Does Jujutsu Work with GitHub?

It does. Because Jujutsu uses Git as its backend, it works fine whether your remote lives on GitHub, GitLab, or Bitbucket. The catch is that Jujutsu shares work through a different concept called a bookmark instead of a branch, and getting comfortable with that can be the real hurdle.

Jujutsu has nothing that corresponds to Git’s named branches. You normally work on anonymous branches, and when it’s time to share, you put a bookmark on whichever commit you want. When you push a bookmarked commit to a remote, Git sees it as a branch. The confusing part is that GitHub treats it as a branch even though it’s a different concept that behaves differently. Newcomers often find these points surprising:

• A bookmark doesn’t move to your latest commit automatically. You move it yourself.
• A mechanism called tracking keeps a bookmark’s position, and its deletion, in sync between local and remote.
• Tracking is practically essential, so local and remote bookmark names must match.
• You can also create a bookmark on the fly at push time with the -c/--change or --named option, even if none exists yet.

Why Jujutsu has bookmarks instead of branches, and what you gain by sharing work through them, is covered in detail in my previous post, “Jujutsu Has No “Create a Branch” Step, and That Finally Made Git Branches Click”.

One way Jujutsu behaves differently from Git after you push: if you rewrite commits you’ve already pushed and push again, it becomes a force push without you doing anything special. Jujutsu always pushes in a way that’s close to --force-with-lease, and accidental rewrites are guarded against locally by whether each commit is mutable or immutable. By default, though, pushed commits outside of trunk are still mutable, so you can rewrite them, and pushing the result ends up as a force push.

This can clash with the policy of teams that develop on shared feature branches. In that case, change which commits count as immutable with a setting like this⁶:

[revset-aliases]
'immutable_heads()' = 'builtin_immutable_heads() | remote_bookmarks("feature/*", "origin")'

Beyond that, opening, approving, and merging PRs, and CI/CD with GitHub Actions and the like, work almost exactly the same with Jujutsu. About the only difference is that when you delete the remote branch on GitHub after merging a PR, the next jj git fetch deletes the linked local bookmark too.

Q4. So What Does Jujutsu Actually Give You Over Git?

Compared with Git, here’s what you get by switching to Jujutsu:

• No index (staging area). There’s nothing like git add to run.
• Commits happen automatically. Whenever you run a jj command and files have changed since the latest commit, Jujutsu takes a new snapshot and updates the commit.
• Thanks to those two, the working copy (what Git calls the working tree) is treated as a commit in its own right. You can move around history like a time machine without worrying about uncommitted changes or keeping the index consistent, as you would in Git.
• When you rewrite any commit, its descendants are rebased automatically.
• However many conflicts a rebase hits, it finishes normally without dropping you into an interactive mode, leaving the conflicts in place. Because conflicted states are recorded in history, redoing a resolution or handing it to a tool is easy.
• Apart from anything that touches a remote, jj undo can undo almost any operation.
• Every jj command that changes the repository, and every automatic snapshot, is recorded in the operation log. Later, you can restore the repository to an earlier state or revert a specific operation.
• No need to create and name a branch just to experiment. Start with jj new, and if you don’t like where it’s going, throw it away with jj abandon and try again.
• The commands are straightforward and easy to remember. Squashing, for example, is jj squash --from A --into B. Options that specify what to operate on and where to put it, like -f/--from, -t/--into, -o/--onto, -A/--insert-after, and -B/--insert-before, work consistently across related commands.

Q5. Is the Learning Curve Steep?

You don’t need many commands to get started. With just these, you should be able to handle the whole basic workflow:

Even this much gets you the benefits of automatic commits and undo, and if those feel valuable, you’ve cleared the first hurdle. The trouble comes after that. The more Git experience people have, the more likely they are to use Jujutsu with their Git mental model intact, looking things up in a command mapping table⁷. That way, you’re just translating Git operations one by one, missing much of what makes Jujutsu useful while adding the chore of translating commands.

Jujutsu was designed to fix what makes Git hard to use. It stays compatible with Git but rethinks the mental model from the ground up. To get the most out of it, you have to follow Yoda’s advice: “You must unlearn what you have learned.”

That’s why the next stage is the hard part. The difficulty doesn’t come from Jujutsu being complicated. It comes from having to rethink version control habits you’ve built up over years with Git, and let go of concepts you’ve always taken for granted. Every now and then I see people who never realize this, keep running their Git workflow on top of Jujutsu, feel no benefit, and go back to Git.

In my experience, focusing on these three things is the quickest way to develop a Jujutsu mental model:

1. Understand what a change is, Jujutsu’s usual unit of history
   • Think of a change as a container with a name and an ID that never changes, and of commits (also called revisions) as successive versions of a document stored inside it. It’s not technically precise, but it’s an easy picture for beginners
2. Drop the idea that you commit only once your work is finished
   • In Jujutsu, every time you change code or the description (roughly, the commit message), it’s as if git commit --amend --no-edit runs instantly and automatically. Changes are unfinished by default, and when you reach a stopping point, you simply move on to another change
   • Don’t use jj commit, which runs jj desc and then jj new in one step and exists to support Git-style workflows
3. Get used to not having a “current branch” while you work
   • Stick to one flow: work on an anonymous branch, and set a bookmark only when you want to share
   • Build the habit of checking where you are in the graph that jj log draws, instead of by branch name

Once you let go of your Git workflow and keep working the Jujutsu way, the logic behind its design starts to click. By then, Jujutsu will feel like second nature, and you won’t want to work without it.

Q6. Jujutsu Isn’t 1.0 Yet. Is It Safe to Use at Work?

The short answer: if the issues in Q2 don’t affect you, there’s almost nothing stopping you in practice. The CLI and configuration will keep changing, though, so whether you can live with that is the real question when deciding to adopt it.

The README in the official GitHub repository says:

Jujutsu is an experimental version control system. While Git compatibility is stable, and most developers use it daily for all their needs, there may still be work-in-progress features, suboptimal UX, and workflow gaps that make it unusable for your particular use.

It also says that workflows may change and that backward-incompatible changes to the on-disk format may come before 1.0, adding that the project will try to provide transparent upgrades when the format changes.

That might sound a little worrying, but there haven’t been any big breaking changes recently. Most of them have been removals of deprecated settings and command options, or changes to system requirements. v0.38.0, released in February 2026, moved where per-repository config files are stored, but that was for security reasons, a necessary step to protect users from malicious attacks.

Martin von Zweigbergk, a former Google engineer, started Jujutsu as a side project in late 2019, and the first version on GitHub, v0.3.0, came out in March 2022. That’s four and a half years ago. Since v0.9.0 in September 2023, a new version has shipped almost every month. It may not be 1.0 yet, but it has a solid track record behind it.

As of October 2026, the official GitHub repository has about 32,000 stars. The project has nine maintainers, and each release credits around 30 contributors. Engineers from several companies, Google among them, contribute on an ongoing basis, and the official docs list the companies that pay for Jujutsu contributions along with their contributing employees⁸.

What about real-world adoption? I mentioned that the creator came from Google. According to him, about 900 people inside Google were already using Jujutsu as of September 2025⁹. In July 2026, he became CTO of ERSC, a hosting platform company whose storage is designed around Jujutsu’s model and which plans to support a native protocol for Jujutsu clients in the future. The fact that companies are building businesses with Jujutsu at their core is one good sign of its reliability.

On top of that, GitHub stacked pull requests, which split a PR into a chain of small, dependent PRs, recently became generally available, and their documentation includes a page that walks through a workflow using Jujutsu¹⁰. It’s fair to read this as a sign that GitHub sees Jujutsu as a compatible client with too many users to ignore, and one worth supporting.

I don’t think Jujutsu is still pre-1.0 because of concerns about its quality or reliability. Rather, I suspect the developers want to keep the freedom to change its design while it continues to evolve. Many developers already use it every day, and companies continue to back its development. At the very least, being pre-1.0 is no reason on its own to avoid using it at work.

Q7. Why Is It Called “Jujutsu”?

A lot of people assume the name comes from the anime Jujutsu Kaisen. In Japan, it even gets teased on social media for sounding a bit edgy and over-the-top. But Jujutsu has nothing to do with Jujutsu Kaisen.

So where does the name come from? The official README on GitHub suggests that the command name jj came first:

The command-line tool is called jj for now because it’s easy to type and easy to replace (rare in English). The project is called “Jujutsu” because it matches “jj”.

With your right index finger resting on J on the home row, it’s just two taps, so it really is easy to type. The README makes it sound as if Jujutsu was picked as a name that fits jj from the start, but the project actually had a different name at first. On crates.io, Rust’s official package registry, there’s a VCS called Jujube. Its author is Martin von Zweigbergk, and it has two versions, 0.1.0 and 0.1.1, released in January 2021. Yes, this is Jujutsu’s predecessor. Here’s what its page says about the name:

The command-line tool is called jj for now because it’s easy to type and easy to replace (rare in English). The project is called “Jujube” (a fruit) because that’s the first word I could think of that matched “jj”.

A jujube is a fruit, also known as a red date or Chinese date, and again it was chosen simply because it matched jj. Just four months later, the name changed. The commit message from that rename is still there:

project: rename project from Jujube to Jujutsu “Jujutsu” is probably much more familiar and relatable to most people. Also, I’m still not sure how “jujube” is supposed to be pronounced :P

The author apparently had no particular attachment to Jujube, and switched to Jujutsu because it was more familiar and relatable. When someone later asked where the name came from¹¹, he pointed to the Wikipedia article on jujutsu, so it refers to the Japanese martial art. In English, the traditional Japanese art is usually spelled “jujutsu,” while “jiu-jitsu” is the spelling most people know from Brazilian jiu-jitsu. Wikipedia does have a separate Brazilian jiu-jitsu article, but searching for “jiu-jitsu” or “jiujitsu” redirects you to the jujutsu article. Without that redirect, the project might be called Jiu-jitsu today.

So is it settled that the name means the martial art? Not quite. The author says he never gave the name any special meaning. When someone proposed renaming Jujutsu to Jojo¹², he didn’t seem very attached to Jujutsu either, suggesting they could hold a vote. There was also a proposal to officially adopt a different meaning and pronunciation¹³. In Japanese, “jujutsu” can stand for two different words: 柔術 (jūjutsu, the martial art) and 呪術 (jujutsu, sorcery or curses, the word in Jujutsu Kaisen). The proposal was to make 呪術 the official one, and the author himself liked the idea at first. In the end, though, defining an official meaning or pronunciation was set aside.

The official logo, in use since 2025, shows the same stance of not giving the name any particular meaning.

Two blue birds sit back to back. They’re jays, members of the crow family. Put two of them together and you get “jay jay.” Not just the name, but the logo too is a pun on jj. If the martial art were the official meaning, the logo would surely show something related to it, but it doesn’t.

In the end, it all started with jj, a short command name that’s easy to type. The project was named Jujutsu after the martial art, yet officially it means neither 柔術 nor 呪術. Jujutsu is just Jujutsu, and that’s probably the real answer to where the name comes from.

Still Have Questions?

Those are seven questions Git users are likely to have when they’re thinking about giving Jujutsu a try. Some of these answers are reworked from the FAQ in Chapter 5, “The Jujutsu Problem-Solving Guide,” of my book, Juju-chu! Starting Your Jujutsu×AI Workflow with `jj new`.

Juju-chu! — Starting Your Jujutsu × AI Workflow with `jj new`A hands-on book on adopting Jujutsu (jj) with Claude Code and Codex: automatic snapshots, undoable operations, and safe history rewriting.juju-chu.com

The book covers many more of the questions Jujutsu newcomers tend to have, along with how to deal with the problems you’re likely to run into once you start. If you’re getting started with Jujutsu, it should save you a lot of time, so please check it out.