DEV Community: Yuka Ooka

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

Yuka Ooka — Tue, 20 Oct 2026 00:00:00 +0000

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:

What you want to do	Command
Check the status	`jj st`
View the log	`jj log`
View the diff	`jj diff`
Update the commit message	`jj desc -m '...'`
Start the next piece of work	`jj new`
Undo the last operation	`jj undo`
Set a bookmark	`jj bookmark set <name>`
Fetch from the remote	`jj git fetch`
Push to the remote	`jj git push -b <bookmark>`

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:

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
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
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.

Footnotes

Besides Git, Jujutsu can also use Piper, the version control system used inside Google, as a backend, but that part isn’t public. A native Jujutsu backend seems to be on the wish list, but no concrete plan has been announced. ↩
“Submodule support - Development roadmap - Jujutsu docs” “Add support for Git submodules · Issue #494 · jj-vcs/jj” ↩
“About large files on GitHub - GitHub Docs” ↩
“Add support for Git LFS · Issue #80 · jj-vcs/jj” ↩
“jj/lib/src/git_subprocess.rs at main · jj-vcs/jj” ↩
The official docs also show other settings, such as one that prevents you from rewriting commits created by other people. “Set of immutable commits - Configuration - Jujutsu docs” ↩
The official docs provide one too. “Git command table - Jujutsu docs” ↩
“Paying employers and their contributing employees - Jujutsu docs” ↩
“JJ Con • Keynote - YouTube” ↩
“Use other tools with stacked pull requests - GitHub Docs” ↩
“Question: What’s ‘jujutsu’ from? · jj-vcs/jj · Discussion #3021” ↩
“Proposal: Rename Jujutsu to Jojo · jj-vcs/jj · Discussion #2520” ↩
“meta: cement “Jujutsu” (呪術) as the project name by thoughtpolice · Pull Request #3042 · jj-vcs/jj” ↩

¿Jujutsu funciona con GitHub? ¿De dónde viene el nombre? 7 preguntas y respuestas

Yuka Ooka — Tue, 20 Oct 2026 00:00:00 +0000

Q1. ¿Puedo usar Jujutsu con mis repositorios de Git existentes?

Sí. Jujutsu es altamente compatible con Git, y basta con ejecutar jj git init dentro de un repositorio de Git existente para empezar a usarlo. No pierdes nada por probarlo y no tienes que dejar Git.

La capa de almacenamiento de Jujutsu es modular, y Git es el backend por defecto¹. El backend de Git guarda los commits como objetos de Git normales, así que el historial que creas con Jujutsu también se puede consultar con las herramientas de Git.

Un repositorio en el que Jujutsu y Git conviven se llama colocated. Antes tenías que pasarle la opción --colocate a jj git init, o a jj git clone al copiar un repositorio remoto, para configurarlo así. Desde la v0.34.0, publicada en octubre de 2025, colocated es la opción por defecto. Todavía vas a ver --colocate en artículos viejos, pero hoy puedes omitirla sin problema.

En un repositorio colocated, hay un directorio .jj/ junto a .git/ en la raíz. El .gitignore que está dentro de .jj/ contiene /*, así que agregar Jujutsu no toca el .gitignore de la raíz. Como mencioné antes, el historial de commits de Git se sigue actualizando mientras usas Jujutsu, y puedes hacer push a GitHub o a cualquier otro remoto como siempre. También soporta commits firmados, así que funciona en repositorios que los exigen. En otras palabras, si quieres, puedes ser la única persona que usa Jujutsu en un equipo que trabaja con Git.

Los comandos de Git también siguen funcionando en un repositorio colocated. Y si decides que Jujutsu no es para ti, puedes volver a Git borrando el directorio .jj/. Jujutsu deja tu configuración de Git tal como está, lo que hace que probarlo no tenga prácticamente ningún costo ni riesgo.

Q2. ¿Qué cosas puede hacer Git que Jujutsu todavía no?

Pese a toda su compatibilidad con Git, Jujutsu todavía no soporta algunas funciones de Git, ni siquiera en la v0.46.0, la versión más reciente a octubre de 2026. Estas tres son las que más problemas suelen causar en proyectos reales:

Submódulos
LFS (Large File Storage)
Hooks de Git o un equivalente directo

La más grave es probablemente la falta de soporte para submódulos. Los submódulos de Git te permiten incrustar otro repositorio Git independiente como un subdirectorio, normalmente para compartir código entre proyectos.

Que no tengan soporte no significa que vayas a perder el contenido de tus submódulos. El verdadero problema es que no se actualizan automáticamente cuando te mueves por el historial. Con jj edit puedes saltar a cualquier punto del historial como en una máquina del tiempo y ver o editar los archivos ahí, pero los directorios de los submódulos se quedan como estaban. Tienes que ejecutar git submodule update --recursive manualmente cada vez.

Jujutsu también ignora los cambios que haces dentro de un submódulo, así que para registrarlos en el historial tienes que ejecutar git add y git commit tú mismo. Puedes trabajar en un repositorio con submódulos, pero tienes que entender las limitaciones y encargarte a mano de las operaciones que no están soportadas.

Del lado del desarrollo, los submódulos no encajan bien con el modelo de datos de Jujutsu, y soportarlos requeriría grandes cambios de diseño, que es una de las principales razones por las que el soporte se ha retrasado. Está en la hoja de ruta, pero buena parte de la documentación de diseño sigue sin terminar y no hay un plazo de implementación a la vista². Hoy en día, los equipos que necesitan compartir código suelen elegir un monorepo o paquetes privados en algo como GitHub Packages en lugar de submódulos. Si te toca tomar esa decisión, vale la pena considerar esas opciones para los proyectos nuevos.

Git LFS es una extensión de Git para video, audio, binarios grandes y otros archivos pesados. Guarda los datos grandes fuera del repositorio y mantiene en Git solo punteros a ellos. En GitHub, Git LFS es actualmente la única forma de gestionar en un repositorio archivos de más de 100 MB³.

Se usa mucho en áreas como el desarrollo de videojuegos, y tampoco está soportado. Se está trabajando en ello, con varios PRs ya abiertos⁴, pero quedan algunas cuestiones de diseño sin resolver, incluidas algunas que afectan a otras funciones. Todavía no hay un plazo claro para su lanzamiento.

Por último, los hooks de Git. Los hooks ejecutan tus propios scripts en respuesta a acciones específicas de Git, y muchos más equipos dependen de ellos que de las otras dos funciones. Los usos típicos son correr formateadores y linters antes de un commit, o tests y auditorías de seguridad antes de un push. Husky con lint-staged, y Lefthook, son las herramientas populares para esto.

Los comandos de Jujutsu nunca disparan los hooks de Git. jj git push, por ejemplo, llama a git push internamente, pero le pasa --no-verify para saltarse los hooks a propósito⁵. Oficialmente, no hay forma de disparar los hooks de Git en el momento que elijas, ni tampoco un mecanismo de hooks propio de Jujutsu.

La razón es que los hooks no encajan con el diseño central ni con el modelo de datos de Jujutsu. Destacan un par de factores:

Jujutsu hace commit de tus cambios en los archivos automáticamente mientras trabajas, así que no hay un paso explícito de commit antes del cual puedan correr los hooks.
Jujutsu reescribe código sin pasar por tu directorio de trabajo, por ejemplo, al hacer squash o cuando la edición de un commit anterior provoca un rebase automático de sus descendientes. Que las pruebas pasen en el commit original no garantiza que sigan pasando después.

Aunque no cubren todo lo que hacen los hooks de Git, Jujutsu sí ofrece algunas herramientas oficiales que encajan con su modelo. Con jj fix, registras formateadores en tu configuración y, al ejecutarlo, recorre hacia atrás tu historial mutable y formatea los archivos que cambiaron en cada commit. jj run ejecuta un comando externo sobre un solo commit o sobre un rango de commits. Puedes usarlo para correr builds o tests a lo largo de tu historial, y como incorpora a los commits correspondientes los cambios que el comando realiza en los archivos, también sirve para linters con corrección automática u otras herramientas que arreglan código.

¿Y si tu equipo tiene una configuración de hooks bien armada, pensada para Git, y quieres ser la única persona que usa Jujutsu? Hay varios enfoques según la situación, y el tema daría fácilmente para uno o dos artículos, así que aquí lo voy a dejar de lado. Si te interesa, mi libro Juju-chu! —Comienza tu flujo de trabajo Jujutsu × IA con jj new lo trata en la sección 4-3, «Tácticas alternativas para los Git hooks».

Q3. ¿Jujutsu funciona con GitHub?

Sí. Como Jujutsu usa Git como backend, funciona sin problemas tanto si tu remoto está en GitHub como en GitLab o Bitbucket. El detalle es que Jujutsu comparte el trabajo mediante un concepto distinto llamado bookmark en lugar de una rama, y acostumbrarse a eso puede ser el verdadero obstáculo.

Jujutsu no tiene nada que corresponda a las ramas con nombre de Git. Normalmente trabajas en ramas anónimas y, cuando llega el momento de compartir, pones un bookmark en el commit que quieras. Cuando haces push de un commit con bookmark a un remoto, Git lo ve como una rama. Lo confuso es que GitHub lo trata como una rama aunque es un concepto distinto que se comporta de otra manera. A quienes recién empiezan suelen sorprenderles estos puntos:

Un bookmark no se mueve automáticamente a tu commit más reciente; tienes que moverlo tú mismo.
Un mecanismo llamado tracking mantiene sincronizada la posición de un bookmark (y su eliminación) entre el entorno local y el remoto.
El tracking es prácticamente imprescindible, así que los nombres de los bookmarks locales y remotos tienen que coincidir.
También puedes crear un bookmark sobre la marcha al hacer push con la opción -c/--change o --named, aunque todavía no exista ninguno.

Por qué Jujutsu tiene bookmarks en lugar de ramas, y qué ganas al compartir el trabajo con ellos, lo explico en detalle en mi artículo anterior, «Jujutsu no tiene un paso para “crear una rama”, y así por fin entendí las ramas de Git».

Hay una diferencia de comportamiento con Git después de hacer push: si reescribes commits que ya subiste y vuelves a hacer push, se convierte automáticamente en un force push. Jujutsu siempre hace push de una forma parecida a --force-with-lease, y a nivel local estás protegido contra reescrituras accidentales según si cada commit es mutable o inmutable. Sin embargo, por defecto, los commits que ya subiste fuera de trunk siguen siendo mutables, así que puedes reescribirlos, y al hacer push del resultado terminas haciendo un force push.

Esto puede chocar con la política de los equipos que desarrollan en feature branches compartidas. En ese caso, cambia qué commits se consideran inmutables con una configuración como esta⁶:

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

Fuera de eso, abrir, aprobar y hacer merge de PRs, y el CI/CD con GitHub Actions y similares, funcionan casi exactamente igual con Jujutsu. Prácticamente la única diferencia es que, cuando borras la rama remota en GitHub después de hacer merge de un PR, el siguiente jj git fetch también borra el bookmark local vinculado.

Q4. En resumen, ¿qué ventajas ofrece Jujutsu frente a Git?

Comparado con Git, esto es lo que ganas al cambiarte a Jujutsu:

No hay índice (staging area). No existe un paso como git add que tengas que ejecutar.
Los commits se hacen automáticamente. Cada vez que ejecutas un comando jj y hay archivos que cambiaron desde el último commit, Jujutsu toma una nueva instantánea y actualiza el commit.
Gracias a esas dos cosas, la copia de trabajo (lo que Git llama working tree) se trata como un commit en sí misma. Puedes moverte por el historial como en una máquina del tiempo sin preocuparte por cambios pendientes de commit ni por mantener el índice consistente, como en Git.
Cuando reescribes cualquier commit, se hace rebase automático de sus descendientes.
Por más conflictos que surjan en un rebase, este termina normalmente sin forzarte a un modo interactivo y deja los conflictos en su lugar. Como los estados con conflictos quedan registrados en el historial , rehacer una resolución o dejársela a una herramienta es fácil.
Excepto por las operaciones que afectan al remoto, jj undo puede deshacer casi cualquier cambio.
Cada comando jj que modifica el repositorio, y cada instantánea automática, se anota en el registro de operaciones (operation log). Más adelante puedes restaurar el repositorio a un estado anterior o revertir una operación específica.
No hace falta crear una rama ni ponerle nombre solo para experimentar. Empieza con jj new y, si no te gusta cómo va, descártalo con jj abandon y vuelve a intentarlo.
Los comandos son directos y fáciles de recordar. Hacer squash, por ejemplo, es jj squash --from A --into B. Las opciones que indican sobre qué operar y dónde ponerlo, como -f/--from, -t/--into, -o/--onto, -A/--insert-after y -B/--insert-before, funcionan de forma consistente en los comandos relacionados.

Q5. ¿Es muy pronunciada la curva de aprendizaje?

No necesitas muchos comandos para empezar. Con solo estos, deberías poder manejar todo el flujo de trabajo básico:

Lo que quieres hacer	Comando
Ver el estado	`jj st`
Ver el log	`jj log`
Ver el diff	`jj diff`
Actualizar el mensaje del commit	`jj desc -m '...'`
Empezar el siguiente trabajo	`jj new`
Deshacer la última operación	`jj undo`
Poner un bookmark	`jj bookmark set <name>`
Traer cambios del remoto	`jj git fetch`
Hacer push al remoto	`jj git push -b <bookmark>`

Con solo esto ya aprovechas los commits automáticos y el undo, y si eso te parece valioso, ya superaste el primer obstáculo. El problema viene después. Mientras más experiencia tenga alguien con Git, más probable es que use Jujutsu con su modelo mental de Git intacto, consultando una tabla de equivalencias de comandos⁷. Así, solo estás traduciendo operaciones de Git una por una: te pierdes buena parte de lo que hace útil a Jujutsu y encima sumas la tarea de traducir comandos.

Jujutsu se diseñó para resolver lo que hace difícil usar Git. Se mantiene compatible con Git, pero replantea el modelo mental desde cero. Para sacarle el máximo provecho, tienes que seguir el consejo de Yoda: «Debes desaprender lo que has aprendido».

Por eso la siguiente etapa es la difícil. La dificultad no viene de que Jujutsu sea complicado. Viene de tener que replantear hábitos de control de versiones que construiste durante años con Git, y soltar conceptos que siempre diste por sentados. De vez en cuando veo gente que nunca se da cuenta de esto, sigue usando su flujo de trabajo de Git sobre Jujutsu, no siente ningún beneficio y vuelve a Git.

En mi experiencia, enfocarse en estas tres cosas es la forma más rápida de desarrollar un modelo mental de Jujutsu:

Entiende qué es un change, la unidad habitual del historial en Jujutsu
- Piensa en un change como un contenedor con un nombre y un ID que nunca cambia, y en los commits (también llamados revisiones) como versiones sucesivas de un documento guardadas dentro de él. No es técnicamente preciso, pero es una imagen fácil para quienes empiezan
Olvídate de la idea de que solo haces commit cuando terminaste tu trabajo
- En Jujutsu, cada vez que cambias el código o la descripción (más o menos, el mensaje del commit), es como si git commit --amend --no-edit se ejecutara al instante y de forma automática. Los changes están sin terminar por defecto y, cuando llegas a un buen punto para parar, simplemente pasas a otro change
- No uses jj commit, que ejecuta jj desc y luego jj new en un solo paso y existe para soportar flujos de trabajo al estilo de Git
Acostúmbrate a no tener una «rama actual» mientras trabajas
- Apégate a un solo flujo: trabaja en una rama anónima y pon un bookmark solo cuando quieras compartir
- Desarrolla el hábito de ubicarte en el grafo que dibuja jj log, en lugar de guiarte por el nombre de una rama

Una vez que sueltas tu flujo de trabajo de Git y sigues trabajando a la manera de Jujutsu, la lógica detrás de su diseño empieza a encajar. Para entonces, usar Jujutsu se sentirá completamente natural y no vas a querer trabajar sin él.

Q6. Jujutsu todavía no está en la 1.0. ¿Es seguro usarlo en el trabajo?

La respuesta corta: si los problemas de la Q2 no te afectan, en la práctica casi no hay nada que te lo impida. Eso sí, la CLI y la configuración van a seguir cambiando, así que la verdadera pregunta al decidir adoptarlo es si puedes vivir con eso.

El README del repositorio oficial en GitHub dice:

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.

(Jujutsu es un sistema de control de versiones experimental. Aunque la compatibilidad con Git es estable y la mayoría de los desarrolladores lo usan a diario para todo lo que necesitan, todavía puede haber funciones en desarrollo, una UX mejorable y huecos en los flujos de trabajo que lo vuelvan inutilizable para tu caso particular).

También dice que los flujos de trabajo pueden cambiar y que podría haber cambios incompatibles en el formato de los datos en disco antes de la 1.0, y agrega que el proyecto intentará ofrecer actualizaciones transparentes cuando el formato cambie.

Puede sonar un poco preocupante, pero últimamente no ha habido grandes cambios incompatibles. La mayoría han sido eliminaciones de configuraciones y opciones de comandos obsoletas, o cambios en los requisitos del sistema. La v0.38.0, publicada en febrero de 2026, cambió dónde se guardan los archivos de configuración de cada repositorio, pero fue por razones de seguridad, un paso necesario para proteger a los usuarios de ataques maliciosos.

Martin von Zweigbergk, ex ingeniero de Google, empezó Jujutsu como proyecto personal a fines de 2019, y la primera versión en GitHub, la v0.3.0, salió en marzo de 2022. Eso fue hace cuatro años y medio. Desde la v0.9.0, en septiembre de 2023, sale una nueva versión casi todos los meses. Puede que todavía no sea 1.0, pero tiene una trayectoria sólida.

A octubre de 2026, el repositorio oficial en GitHub tiene unas 32 000 estrellas. El proyecto tiene nueve maintainers, y cada release da crédito a unos 30 colaboradores. Ingenieros de varias empresas, Google entre ellas, contribuyen de forma continua. La documentación oficial enumera las empresas que financian el desarrollo de Jujutsu y los empleados que participan en él⁸.

¿Y la adopción en el mundo real? Mencioné que el creador venía de Google. Según él, unas 900 personas dentro de Google ya usaban Jujutsu en septiembre de 2025⁹. En julio de 2026 pasó a ser CTO de ERSC, una empresa que ofrece una plataforma de hosting cuyo almacenamiento está diseñado en torno al modelo de Jujutsu y que planea soportar en el futuro un protocolo nativo para clientes de Jujutsu. Que haya empresas que basan su negocio en Jujutsu es una buena señal de su confiabilidad.

Además, los stacked pull requests de GitHub, que dividen un PR en una cadena de PRs pequeños y dependientes, pasaron hace poco a disponibilidad general, y su documentación incluye una página que explica un flujo de trabajo con Jujutsu¹⁰. Es razonable leer esto como una señal de que GitHub ve a Jujutsu como un cliente compatible, con demasiados usuarios como para ignorarlo, y al que vale la pena dar soporte.

No creo que la falta de una 1.0 se deba a dudas sobre su calidad o su confiabilidad. Más bien, sospecho que los desarrolladores quieren conservar la libertad de cambiar su diseño mientras sigue evolucionando. Muchos desarrolladores ya lo usan todos los días, y hay empresas que siguen respaldando su desarrollo. Como mínimo, no haber llegado a la 1.0 no es por sí solo un motivo para evitar usarlo en el trabajo.

Q7. ¿Por qué se llama «Jujutsu»?

Mucha gente da por hecho que el nombre viene del anime Jujutsu Kaisen. En Japón, hasta se burlan de él en redes sociales por sonar un poco sobrado, como nombre de anime que quiere quedar intenso. Pero Jujutsu no tiene nada que ver con Jujutsu Kaisen.

Entonces, ¿de dónde viene el nombre? El README oficial en GitHub sugiere que primero vino el nombre del comando, jj:

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”.

Con el índice derecho apoyado en la J de la fila guía, son solo dos toques, así que de verdad es fácil de escribir. El README da a entender que Jujutsu se eligió desde el principio como un nombre que encajaba con jj, pero en realidad el proyecto tuvo otro nombre al comienzo. En crates.io, el registro oficial de paquetes de Rust, hay un VCS llamado Jujube. Su autor es Martin von Zweigbergk, y tiene dos versiones, 0.1.0 y 0.1.1, publicadas en enero de 2021. Así es: es el predecesor de Jujutsu. Esto es lo que dice su página sobre el nombre:

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”.

En inglés, jujube es una fruta poco conocida por acá: el dátil chino (azufaifa). Una vez más, el nombre se eligió simplemente porque coincidía con jj. Apenas cuatro meses después, el nombre cambió. El mensaje del commit de ese cambio de nombre sigue ahí:

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

Al parecer, el autor no le tenía un apego especial a Jujube, y se cambió a Jujutsu porque era un nombre más conocido y cercano para la mayoría. Cuando más tarde alguien le preguntó de dónde venía el nombre¹¹, señaló el artículo de Wikipedia sobre el jujutsu, así que se refiere al arte marcial japonés. En inglés, el arte tradicional japonés suele escribirse «jujutsu», mientras que «jiu-jitsu» es la grafía que la mayoría conoce por el jiu-jitsu brasileño. La Wikipedia en inglés tiene un artículo aparte sobre el jiu-jitsu brasileño, pero si buscas «jiu-jitsu» o «jiujitsu», te redirige al artículo sobre el jujutsu. Sin esa redirección, quizá hoy el proyecto se llamaría Jiu-jitsu.

Entonces, ¿queda claro que el nombre se refiere al arte marcial? No del todo. El autor dice que nunca le dio al nombre ningún significado especial. Cuando alguien propuso renombrar Jujutsu a Jojo¹², tampoco pareció muy apegado a Jujutsu, y sugirió que podían hacer una votación. También hubo una propuesta para adoptar oficialmente otro significado y otra pronunciación¹³. En japonés, «jujutsu» puede corresponder a dos palabras distintas: 柔術 (jūjutsu, el arte marcial) y 呪術 (jujutsu, hechicería, la palabra de Jujutsu Kaisen; las maldiciones son otra palabra). La propuesta era hacer oficial 呪術, y al propio autor la idea le gustó al principio. Al final, sin embargo, se dejó de lado definir un significado o una pronunciación oficiales.

El logo oficial, que se usa desde 2025, muestra la misma postura de no darle al nombre ningún significado en particular.

El logo muestra dos pájaros azules de espaldas uno al otro. Son arrendajos, de la familia de los cuervos, llamados jays en inglés. La palabra jay se pronuncia igual que la letra J en inglés: dos arrendajos forman «jay jay», es decir, jj. No solo el nombre: el logo también es un juego de palabras con jj. Si el arte marcial fuera el significado oficial, el logo seguramente mostraría algo relacionado con él, pero no es así.

Al final, todo empezó con jj, un nombre de comando corto y fácil de escribir. El proyecto se llamó Jujutsu por el arte marcial y, aun así, oficialmente no significa ni 柔術 ni 呪術. Jujutsu es simplemente Jujutsu, y probablemente esa sea la verdadera respuesta a la pregunta de dónde viene el nombre.

¿Todavía te quedan preguntas?

Estas fueron siete preguntas que suelen hacerse los usuarios de Git cuando consideran darle una oportunidad a Jujutsu. Algunas de estas respuestas están reelaboradas a partir de las preguntas frecuentes del capítulo 5, «Guía de resolución de problemas de Jujutsu», de mi libro Juju-chu! —Comienza tu flujo de trabajo Jujutsu × IA con jj new.

Juju-chu! —Comienza tu flujo de trabajo Jujutsu × IA con jj new

Una guía práctica para adoptar Jujutsu (jj) junto a Claude Code y Codex: snapshots automáticos, operaciones que siempre se pueden deshacer y una reescritura del historial que es segura.

juju-chu.com

El libro responde muchas más de las preguntas que suelen tener quienes recién llegan a Jujutsu, y explica cómo resolver los problemas con los que probablemente te encuentres cuando empieces. Si estás arrancando con Jujutsu, debería ahorrarte mucho tiempo, así que échale un vistazo.

Footnotes

Además de Git, Jujutsu también puede usar como backend Piper, el sistema de control de versiones que se usa dentro de Google, pero esa parte no es pública. Un backend nativo de Jujutsu parece estar en la lista de deseos, pero no se ha anunciado ningún plan concreto. ↩
“Submodule support - Development roadmap - Jujutsu docs” “Add support for Git submodules · Issue #494 · jj-vcs/jj” ↩
“Acerca de los archivos grandes en GitHub - Documentación de GitHub” ↩
“Add support for Git LFS · Issue #80 · jj-vcs/jj” ↩
“jj/lib/src/git_subprocess.rs at main · jj-vcs/jj” ↩
La documentación oficial también muestra otras configuraciones, como una que impide reescribir commits creados por otras personas. “Set of immutable commits - Configuration - Jujutsu docs” ↩
La documentación oficial también tiene una. “Git command table - Jujutsu docs” ↩
“Paying employers and their contributing employees - Jujutsu docs” ↩
“JJ Con • Keynote - YouTube” ↩
“Usa otras herramientas con pull requests apiladas - Documentación de GitHub” ↩
“Question: What’s ‘jujutsu’ from? · jj-vcs/jj · Discussion #3021” ↩
“Proposal: Rename Jujutsu to Jojo · jj-vcs/jj · Discussion #2520” ↩
“meta: cement “Jujutsu” (呪術) as the project name by thoughtpolice · Pull Request #3042 · jj-vcs/jj” ↩

O Jujutsu funciona com o GitHub? De onde vem o nome? 7 perguntas e respostas

Yuka Ooka — Tue, 20 Oct 2026 00:00:00 +0000

Q1. Dá para usar o Jujutsu nos meus repositórios Git atuais?

Dá, sim. O Jujutsu é altamente compatível com o Git, e basta rodar jj git init dentro de um repositório Git existente para começar a usar o Jujutsu nele. Você não perde nada ao experimentar e não precisa abrir mão do Git.

A camada de armazenamento do Jujutsu é plugável, e o Git é o backend padrão¹. O backend do Git guarda os commits como objetos Git comuns, então o histórico que você cria com o Jujutsu também pode ser acessado pelas ferramentas do Git.

Um repositório em que o Jujutsu e o Git convivem lado a lado é chamado de colocated. Antes, para ter um, você precisava passar a opção --colocate para o jj git init, ou para o jj git clone ao copiar um repositório remoto. Desde a v0.34.0, lançada em outubro de 2025, colocated é o padrão. Você ainda vai ver --colocate em artigos mais antigos, mas hoje pode ignorar essa opção sem medo.

Num repositório colocated, um diretório .jj/ fica ao lado do .git/ na raiz. O .gitignore dentro do .jj/ contém /*, então adicionar o Jujutsu não mexe no .gitignore da raiz. Como mencionei acima, o histórico de commits do Git continua sendo atualizado enquanto você usa o Jujutsu, e você pode fazer push para o GitHub ou qualquer outro remoto normalmente. Commits assinados também são suportados, então ele funciona em repositórios que os exigem. Ou seja, se quiser, você pode ser a única pessoa de um time de Git que usa o Jujutsu.

Os comandos do Git também continuam funcionando num repositório colocated. E, se você decidir que o Jujutsu não é para você, dá para voltar ao Git apagando o diretório .jj/. O Jujutsu deixa a sua configuração do Git do jeito que está, então testá-lo não traz praticamente nenhum custo nem risco.

Q2. O que o Git faz que o Jujutsu não faz?

Apesar de toda a compatibilidade com o Git, o Jujutsu ainda não suporta alguns recursos do Git, nem mesmo na v0.46.0, a versão mais recente em outubro de 2026. Três deles são os que têm mais chance de causar problemas em projetos reais:

Submódulos
LFS (Large File Storage)
Hooks do Git ou um equivalente direto

O mais sério deles provavelmente é a falta de suporte a submódulos. Os submódulos do Git permitem embutir outro repositório Git independente como um subdiretório, normalmente para compartilhar código entre projetos.

Não ter suporte não significa que o conteúdo dos seus submódulos se perde. O verdadeiro problema é que o conteúdo deles não se atualiza automaticamente quando você se move pelo histórico. Com jj edit, dá para pular para qualquer ponto do histórico como numa máquina do tempo e ver ou editar os arquivos ali, mas os diretórios dos submódulos ficam como estavam. Você precisa rodar git submodule update --recursive na mão toda vez.

O Jujutsu também ignora as alterações que você faz dentro de um submódulo, então, para registrá-las no histórico, você precisa rodar git add e git commit por conta própria. Ainda dá para trabalhar num repositório com submódulos, mas você precisa entender as limitações e cuidar na mão das operações que não são suportadas.

Do lado do desenvolvimento, os submódulos não combinam bem com o modelo de dados do Jujutsu, e suportá-los exigiria grandes mudanças de design, o que é um dos principais motivos do atraso. Isso está no roadmap, mas boa parte da documentação de design ainda não está pronta, e não há previsão de implementação². Hoje em dia, times que precisam compartilhar código costumam escolher um monorepo ou pacotes privados em algo como o GitHub Packages em vez de submódulos. Se a decisão for sua, vale a pena considerar essas opções em projetos novos.

O Git LFS é uma extensão do Git para vídeo, áudio, binários grandes e outros arquivos pesados. Ele guarda os dados grandes fora do repositório e mantém no Git só ponteiros para eles. No GitHub, o Git LFS é hoje a única forma de gerenciar num repositório arquivos com mais de 100 MB³.

Ele é muito usado em áreas como desenvolvimento de jogos, e também não é suportado. O trabalho está em andamento, com vários PRs já abertos⁴, mas ainda há questões de design em aberto, incluindo algumas que afetam outros recursos. Ainda não há uma previsão clara de lançamento.

Por fim, os hooks do Git. Os hooks executam scripts próprios em resposta a ações específicas do Git, e muito mais times dependem deles do que dos outros dois recursos. Os usos típicos são rodar formatadores e linters antes de um commit, ou testes e auditorias de segurança antes de um push. Husky com lint-staged, e Lefthook, são as ferramentas populares para isso.

Os comandos do Jujutsu nunca disparam hooks do Git. O jj git push, por exemplo, chama o git push internamente, mas passa --no-verify para pular os hooks de propósito⁵. Oficialmente, não há como disparar os hooks do Git no momento que você quiser, nem um mecanismo de hooks próprio do Jujutsu.

O motivo é que os hooks não combinam com o design central e o modelo de dados do Jujutsu. Dois fatores se destacam:

O Jujutsu faz commit das suas alterações automaticamente enquanto você trabalha, então não existe uma etapa explícita de commit antes da qual os hooks possam rodar.
O Jujutsu reescreve código sem passar pelo seu diretório de trabalho, por exemplo, quando você faz squash ou quando a edição de um commit antigo provoca um rebase automático dos seus descendentes. Passar nos testes no commit original não garante que eles continuem passando lá na frente.

Embora não cubram tudo o que os hooks do Git fazem, o Jujutsu oferece algumas ferramentas oficiais que se encaixam no modelo dele. Com o jj fix, você registra formatadores na sua configuração e, ao rodá-lo, ele percorre o seu histórico mutável de trás para frente e formata os arquivos alterados em cada commit. O jj run executa um comando externo sobre um único commit ou um intervalo de commits. Dá para usá-lo para rodar builds ou testes ao longo do histórico e, como ele incorpora aos commits correspondentes as alterações que o comando faz nos arquivos, também serve para linters com correção automática ou outras ferramentas que corrigem código.

E se o seu time tiver uma configuração de hooks elaborada, montada em torno do Git, e você quiser ser a única pessoa usando o Jujutsu? Há várias abordagens dependendo da situação, e o assunto renderia fácil um ou dois artigos, então vou deixá-lo de fora aqui. Se tiver curiosidade, meu livro Juju-chu! — Comece seu fluxo de trabalho Jujutsu × IA com jj new trata disso na seção “4-3. Táticas alternativas para os Git hooks”.

Q3. O Jujutsu funciona com o GitHub?

Funciona. Como o Jujutsu usa o Git como backend, ele funciona sem problemas esteja o seu remoto no GitHub, no GitLab ou no Bitbucket. O porém é que o Jujutsu compartilha o trabalho por meio de um conceito diferente, chamado bookmark, em vez de um branch, e se acostumar com isso pode ser o verdadeiro obstáculo.

O Jujutsu não tem nada que corresponda aos branches com nome do Git. Normalmente você trabalha em branches anônimos e, na hora de compartilhar, coloca um bookmark no commit que quiser. Quando você faz push de um commit com bookmark para um remoto, o Git o enxerga como um branch. O confuso é que o GitHub trata isso como um branch, embora seja um conceito diferente, com outro comportamento. Quem está começando costuma estranhar estes pontos:

Um bookmark não se move automaticamente para o seu commit mais recente; é você quem precisa movê-lo.
Um mecanismo chamado tracking mantém sincronizada a posição de um bookmark (e também sua exclusão) entre o repositório local e o remoto.
O tracking é praticamente indispensável, então os nomes dos bookmarks locais e remotos precisam ser iguais.
Também dá para criar um bookmark na hora do push com a opção -c/--change ou --named, mesmo que ainda não exista nenhum.

Por que o Jujutsu tem bookmarks em vez de branches, e o que você ganha ao compartilhar o trabalho com eles, eu explico em detalhes no meu post anterior, “O Jujutsu não tem o passo de ‘criar um branch’, e foi isso que finalmente me fez entender os branches do Git”.

Uma diferença de comportamento em relação ao Git depois do push: se você reescrever commits que já enviou e fizer push de novo, isso vira automaticamente um force push. O Jujutsu sempre faz push de um jeito parecido com --force-with-lease, e no nível local você está protegido contra reescritas acidentais dependendo de o commit ser mutável ou imutável. Por padrão, porém, os commits já enviados fora do trunk continuam mutáveis, então você pode reescrevê-los, e fazer push do resultado acaba virando um force push.

Isso pode bater de frente com a política de times que desenvolvem em feature branches compartilhados. Nesse caso, mude quais commits contam como imutáveis com uma configuração como esta⁶:

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

Fora isso, abrir, aprovar e fazer merge de PRs, além de CI/CD com GitHub Actions e afins, funcionam quase exatamente do mesmo jeito com o Jujutsu. Praticamente a única diferença é que, quando você apaga o branch remoto no GitHub depois do merge de um PR, o próximo jj git fetch apaga também o bookmark local vinculado.

Q4. No fim das contas, o que o Jujutsu oferece a mais que o Git?

Comparado com o Git, é isto que você ganha ao mudar para o Jujutsu:

Não existe índice (staging area). Não há nenhuma etapa como git add para rodar.
Os commits acontecem automaticamente. Sempre que você roda um comando jj e há arquivos alterados desde o último commit, o Jujutsu tira um novo snapshot e atualiza o commit.
Graças a essas duas coisas, a cópia de trabalho (o que o Git chama de working tree) é tratada como um commit em si. Você pode andar pelo histórico como numa máquina do tempo sem se preocupar com alterações não commitadas nem em manter o índice consistente, como no Git.
Quando você reescreve qualquer commit, os descendentes dele passam por rebase automaticamente.
Por mais conflitos que um rebase encontre, ele termina normalmente, sem jogar você num modo interativo, e deixa os conflitos no lugar. Como os estados com conflito ficam registrados no histórico , refazer uma resolução ou entregá-la a uma ferramenta é fácil.
Exceto pelas operações que afetam um repositório remoto, o jj undo pode desfazer quase qualquer alteração.
Todo comando jj que altera o repositório, e todo snapshot automático, vai para o registro de operações (operation log). Depois, você pode restaurar o repositório a um estado anterior ou reverter uma operação específica.
Não é preciso criar um branch e dar nome a ele só para experimentar. Comece com jj new e, se não gostar do rumo, descarte com jj abandon e tente de novo.
Os comandos são diretos e fáceis de lembrar. Fazer squash, por exemplo, é jj squash --from A --into B. As opções que indicam sobre o que operar e para onde levar, como -f/--from, -t/--into, -o/--onto, -A/--insert-after e -B/--insert-before, funcionam de forma consistente entre os comandos relacionados.

Q5. A curva de aprendizado é íngreme?

Você não precisa de muitos comandos para começar. Só com estes, já deve dar conta de todo o fluxo de trabalho básico:

O que você quer fazer	Comando
Ver o status	`jj st`
Ver o log	`jj log`
Ver o diff	`jj diff`
Atualizar a mensagem do commit	`jj desc -m '...'`
Começar o próximo trabalho	`jj new`
Desfazer a última operação	`jj undo`
Definir um bookmark	`jj bookmark set <name>`
Buscar do remoto	`jj git fetch`
Fazer push para o remoto	`jj git push -b <bookmark>`

Só com isso você já aproveita os commits automáticos e o undo e, se achar isso valioso, já superou o primeiro obstáculo. O problema vem depois. Quanto mais experiência a pessoa tem com o Git, maior a chance de ela usar o Jujutsu com o modelo mental do Git intacto, consultando uma tabela de equivalência de comandos⁷. Desse jeito, você só está traduzindo operações do Git uma a uma, perde boa parte do que o Jujutsu tem de útil e ainda ganha o trabalho de traduzir comandos.

O Jujutsu foi projetado para resolver o que torna o Git difícil de usar. Ele continua compatível com o Git, mas repensa o modelo mental do zero. Para tirar o máximo proveito dele, você precisa seguir o conselho do Yoda: “Você deve desaprender o que aprendeu.”

É por isso que a etapa seguinte é a difícil. A dificuldade não vem de o Jujutsu ser complicado. Vem de ter que repensar hábitos de controle de versão que você construiu ao longo de anos com o Git, e largar conceitos que você sempre deu como certos. De vez em quando, vejo gente que nunca percebe isso, continua tocando o fluxo de trabalho do Git em cima do Jujutsu, não sente nenhum benefício e volta para o Git.

Pela minha experiência, focar nestas três coisas é o caminho mais rápido para desenvolver um modelo mental do Jujutsu:

Entenda o que é um change, a unidade usual de histórico do Jujutsu
- Pense num change como um contêiner com um nome e um ID que nunca muda, e nos commits (também chamados de revisões) como versões sucessivas de um documento guardadas dentro dele. Não é tecnicamente preciso, mas é uma imagem fácil para quem está começando
Abandone a ideia de que você só faz commit quando o trabalho está pronto
- No Jujutsu, toda vez que você muda o código ou a descrição (grosso modo, a mensagem do commit), é como se um git commit --amend --no-edit rodasse na hora, automaticamente. Os changes estão inacabados por padrão e, quando você chega a um bom ponto de parada, simplesmente passa para outro change
- Não use o jj commit, que roda jj desc e depois jj new de uma vez só e existe para dar suporte a fluxos de trabalho no estilo do Git
Acostume-se a não ter um “branch atual” enquanto trabalha
- Fique num único fluxo: trabalhe num branch anônimo e coloque um bookmark só quando quiser compartilhar
- Crie o hábito de ver onde você está no grafo que o jj log desenha, em vez de se guiar pelo nome do branch

Depois que você larga o fluxo de trabalho do Git e continua trabalhando do jeito do Jujutsu, a lógica por trás do design dele começa a fazer sentido. A essa altura, usar o Jujutsu vai se tornar algo completamente natural, e você não vai mais querer trabalhar sem ele.

Q6. O Jujutsu ainda não chegou à 1.0. É seguro usar no trabalho?

A resposta curta: se os problemas da Q2 não afetam você, na prática quase nada impede você de usar. A CLI e a configuração vão continuar mudando, porém, então a verdadeira questão na hora de decidir pela adoção é se você consegue conviver com isso.

O README no repositório oficial do GitHub diz:

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.

(O Jujutsu é um sistema de controle de versão experimental. Embora a compatibilidade com o Git seja estável e a maioria dos desenvolvedores o use diariamente para tudo de que precisa, ainda pode haver recursos em desenvolvimento, uma UX com espaço para melhorar e lacunas nos fluxos de trabalho que o tornem inviável para o seu caso específico.)

Ele também diz que os fluxos de trabalho podem mudar e que pode haver mudanças incompatíveis no formato dos dados em disco antes da 1.0, acrescentando que o projeto vai tentar oferecer atualizações transparentes quando o formato mudar.

Isso pode soar um pouco preocupante, mas não tem havido grandes mudanças incompatíveis ultimamente. A maioria foi remoção de configurações e opções de comando obsoletas, ou mudança nos requisitos de sistema. A v0.38.0, lançada em fevereiro de 2026, mudou o lugar onde ficam os arquivos de configuração de cada repositório, mas foi por motivos de segurança, um passo necessário para proteger os usuários de ataques maliciosos.

Martin von Zweigbergk, ex-engenheiro do Google, começou o Jujutsu como projeto paralelo no fim de 2019, e a primeira versão no GitHub, a v0.3.0, saiu em março de 2022. Isso foi há quatro anos e meio. Desde a v0.9.0, em setembro de 2023, sai uma versão nova quase todo mês. Pode não ser 1.0 ainda, mas tem um histórico sólido.

Em outubro de 2026, o repositório oficial no GitHub tem cerca de 32 mil estrelas. O projeto tem nove maintainers, e cada release dá crédito a cerca de 30 contribuidores. Engenheiros de várias empresas, entre elas o Google, contribuem de forma contínua. A documentação oficial lista as empresas que financiam o desenvolvimento do Jujutsu e os funcionários que participam dele⁸.

E a adoção no mundo real? Comentei que o criador veio do Google. Segundo ele, cerca de 900 pessoas dentro do Google já usavam o Jujutsu em setembro de 2025⁹. Em julho de 2026, ele se tornou CTO da ERSC, uma empresa que oferece uma plataforma de hospedagem cujo armazenamento foi projetado em torno do modelo do Jujutsu e que planeja suportar no futuro um protocolo nativo para clientes do Jujutsu. O fato de haver empresas que baseiam seus negócios no Jujutsu é um bom sinal da confiabilidade dele.

Além disso, os stacked pull requests do GitHub, que dividem um PR numa cadeia de PRs pequenos e dependentes, ficaram disponíveis para todos há pouco tempo, e a documentação deles inclui uma página que mostra um fluxo de trabalho com o Jujutsu¹⁰. É justo ler isso como sinal de que o GitHub vê o Jujutsu como um cliente compatível, com usuários demais para ser ignorado, e ao qual vale a pena dar suporte.

Não acho que a falta de uma 1.0 se deva a dúvidas sobre a qualidade ou a confiabilidade dele. Na verdade, suspeito que os desenvolvedores queiram manter a liberdade de mudar o design enquanto ele continua evoluindo. Muitos desenvolvedores já o usam todo dia, e há empresas que continuam apoiando o desenvolvimento. No mínimo, não ter chegado à 1.0 não é, por si só, motivo para evitar usá-lo no trabalho.

Q7. Por que o nome “Jujutsu”?

Muita gente acha que o nome vem do anime Jujutsu Kaisen. No Japão, ele é até zoado nas redes sociais por soar meio exagerado, com cara de nome de anime. Mas o Jujutsu não tem nada a ver com Jujutsu Kaisen.

Então, de onde vem o nome? O README oficial no GitHub sugere que o nome do comando, jj, veio primeiro:

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”.

Com o indicador direito apoiado na tecla J, na fileira central do teclado, bastam dois toques, então é mesmo fácil de digitar. O README dá a entender que Jujutsu foi escolhido desde o início como um nome que combinava com jj, mas, na verdade, o projeto teve outro nome no começo. No crates.io, o registro oficial de pacotes do Rust, existe um VCS chamado Jujube. O autor é Martin von Zweigbergk, e ele tem duas versões, 0.1.0 e 0.1.1, lançadas em janeiro de 2021. Isso mesmo: é o antecessor do Jujutsu. Veja o que a página dele diz sobre o nome:

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”.

Em inglês, jujube é o nome de uma fruta: a jujuba (também conhecida como tâmara-chinesa). Mais uma vez, o nome foi escolhido simplesmente porque combinava com jj. Apenas quatro meses depois, o nome mudou. A mensagem de commit dessa troca de nome continua lá:

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

Pelo jeito, o autor não tinha nenhum apego especial a Jujube e trocou para Jujutsu por ser um nome mais conhecido e mais próximo da maioria das pessoas. Quando mais tarde alguém perguntou de onde vinha o nome¹¹, ele apontou o artigo da Wikipédia sobre o jujutsu, então o nome se refere à arte marcial japonesa. Em inglês, a arte tradicional japonesa costuma ser grafada “jujutsu”, enquanto “jiu-jitsu” é a grafia que a maioria conhece por causa do jiu-jitsu brasileiro. A Wikipédia em inglês tem um artigo separado sobre o jiu-jitsu brasileiro, mas quem busca “jiu-jitsu” ou “jiujitsu” é redirecionado para o artigo sobre o jujutsu. Sem esse redirecionamento, talvez o projeto hoje se chamasse Jiu-jitsu.

Então está decidido que o nome se refere à arte marcial? Não exatamente. O autor diz que nunca deu nenhum significado especial ao nome. Quando alguém propôs renomear o Jujutsu para Jojo¹², ele também não pareceu muito apegado a Jujutsu e sugeriu que fizessem uma votação. Também houve uma proposta de adotar oficialmente outro significado e outra pronúncia¹³. Em japonês, “jujutsu” pode corresponder a duas palavras diferentes: 柔術 (jūjutsu, a arte marcial) e 呪術 (jujutsu, feitiçaria, a palavra de Jujutsu Kaisen; maldição é outra palavra). A proposta era tornar 呪術 o significado oficial, e o próprio autor gostou da ideia no começo. No fim, porém, a definição de um significado ou de uma pronúncia oficial ficou de lado.

O logo oficial, em uso desde 2025, mostra a mesma postura de não dar ao nome nenhum significado em particular.

Dois pássaros azuis estão de costas um para o outro. São gaios (aves da família dos corvídeos chamadas jays em inglês). A palavra jay tem a mesma pronúncia da letra J em inglês: dois gaios formam “jay jay”, ou seja, jj. Não só o nome: o logo também é um trocadilho com jj. Se a arte marcial fosse o significado oficial, o logo com certeza mostraria algo ligado a ela, mas não é o caso.

No fim das contas, tudo começou com jj, um nome de comando curto e fácil de digitar. O projeto foi batizado de Jujutsu por causa da arte marcial e, mesmo assim, oficialmente não significa nem 柔術 nem 呪術. Jujutsu é só Jujutsu, e essa provavelmente é a verdadeira resposta para a origem do nome.

Ainda tem dúvidas?

São sete dúvidas comuns que quem usa Git costuma ter quando pensa em dar uma chance ao Jujutsu. Algumas destas respostas foram reelaboradas a partir das perguntas frequentes do capítulo 5, “Guia de solução de problemas do Jujutsu”, do meu livro Juju-chu! — Comece seu fluxo de trabalho Jujutsu × IA com jj new.

Juju-chu! — Comece seu fluxo de trabalho Jujutsu × IA com jj new

Um guia prático para adotar Jujutsu (jj) com Claude Code e Codex: snapshots automáticos, operações que podem ser desfeitas e reescrita segura do histórico.

juju-chu.com

O livro responde a muitas outras perguntas que costumam surgir para quem está chegando ao Jujutsu, além de mostrar como lidar com os problemas que você provavelmente vai encontrar quando começar. Se você está começando com o Jujutsu, ele deve economizar bastante tempo, então dê uma olhada.

Footnotes

Além do Git, o Jujutsu também pode usar como backend o Piper, o sistema de controle de versão usado dentro do Google, mas essa parte não é pública. Um backend nativo do Jujutsu parece estar na lista de desejos, mas nenhum plano concreto foi anunciado. ↩
“Submodule support - Development roadmap - Jujutsu docs” “Add support for Git submodules · Issue #494 · jj-vcs/jj” ↩
“Sobre arquivos grandes no GitHub - Documentos do GitHub” ↩
“Add support for Git LFS · Issue #80 · jj-vcs/jj” ↩
“jj/lib/src/git_subprocess.rs at main · jj-vcs/jj” ↩
A documentação oficial também mostra outras configurações, como uma que impede reescrever commits criados por outras pessoas. “Set of immutable commits - Configuration - Jujutsu docs” ↩
A documentação oficial também tem uma. “Git command table - Jujutsu docs” ↩
“Paying employers and their contributing employees - Jujutsu docs” ↩
“JJ Con • Keynote - YouTube” ↩
“Usar outras ferramentas com pull requests empilhados - Documentos do GitHub” ↩
“Question: What’s ‘jujutsu’ from? · jj-vcs/jj · Discussion #3021” ↩
“Proposal: Rename Jujutsu to Jojo · jj-vcs/jj · Discussion #2520” ↩
“meta: cement “Jujutsu” (呪術) as the project name by thoughtpolice · Pull Request #3042 · jj-vcs/jj” ↩

O Jujutsu não tem o passo de “criar um branch”, e foi isso que finalmente me fez entender os branches do Git

Yuka Ooka — Tue, 13 Oct 2026 12:44:00 +0000

O Jujutsu não tem branches?

Quando comecei a usar o Jujutsu depois de anos seguindo os fluxos de trabalho do Git, a primeira coisa que me deixou perdida foi que não havia nenhum branch ao qual o meu trabalho atual pertencesse. Todo mundo que começa no Git aprende o ritual: antes de fazer qualquer trabalho de verdade, crie um branch. Mesmo num projeto pessoal em que você pula essa etapa, pelo menos você está no branch main.

Só que a documentação oficial e um tutorial bastante conhecido já começam direto no trabalho. Ninguém cria um branch nem troca de branch. Na verdade, por mais que eu procurasse, não encontrava no Jujutsu nada chamado “branch” que desse para manipular. No lugar disso existe uma coisa chamada bookmark , que é mapeado para um branch quando você trabalha com o Git. E, mesmo assim, um bookmark não é a mesma coisa que um branch. Eu não estava entendendo nada.

Mas, depois de fazer push do meu trabalho no Jujutsu e abrir PRs com ele algumas vezes seguindo os guias, me ocorreu uma coisa: talvez o Git e o Jujutsu simplesmente queiram dizer coisas diferentes com a palavra “branch”. Com isso em mente, reli o capítulo sobre branches do Pro Git¹ e a página sobre bookmarks da documentação do Jujutsu, e finalmente a ficha caiu. Um branch do Git não é um “galho” no sentido literal, e faz todo o sentido o Jujutsu chamar o equivalente dele de “bookmark”.

O que “um branch do Git é um ponteiro” quer dizer de verdade

Afinal, o que é exatamente um branch do Git? A seção 3.1 do livro Pro Git descreve o branching assim:

Branching (ramificação) significa que você diverge da linha principal de desenvolvimento e continua a fazer o trabalho sem mexer nessa linha principal.

Lendo um pouco mais adiante, você encontra isto:

Um branch no Git é simplesmente um ponteiro móvel e leve para um desses commits.

[…]

O que acontece quando você cria um novo branch? Bem, fazer isso cria um novo ponteiro para você mover por aí.

“Um branch é um ponteiro.” Se você usa Git há algum tempo, com certeza já ouviu essa frase. Confesso, meio sem graça, que ela nunca me disse muita coisa, e por anos usei branches no feeling. Hoje entendo o porquê. A explicação se apoia em várias premissas que ninguém menciona, e, para quem teve o Git como primeiro VCS, ela não diz muito. A documentação oficial do Git e os livros clássicos foram escritos por veteranos que conheciam bem outros sistemas de controle de versões, e é fácil eles não perceberem que quem começou pelo Git não compartilha essas premissas.

Então, o que é preciso saber para que “um branch é um ponteiro” faça sentido? A primeira coisa é que, no Git, um branch não é a bifurcação do histórico em si. Para separar as duas coisas, o Pro Git usa expressões como “histórico divergente” (divergent history) para se referir à bifurcação propriamente dita².

A maioria dos VCSs distribuídos representa o histórico como um DAG³, e não como uma árvore, então as bifurcações e os merges são expressos inteiramente dentro do grafo. O que muda de um VCS para outro é o mecanismo que ele oferece ao usuário para visualizar e manipular essas bifurcações, e a maioria chama esse mecanismo de “branch”. No Mercurial, que surgiu mais ou menos na mesma época que o Git, um branch é um metadado gravado de forma permanente em cada commit de uma linha do histórico. Já o Git usa um ponteiro para cada linha do histórico, e cada um aponta para um único commit.

Ainda não ficou claro? Então vamos para a segunda premissa. O que diferencia o Git de outros VCSs é que, onde quer que você esteja, ele sempre te empurra automaticamente para a ponta do histórico. Nos VCSs anteriores, criar branches e alternar entre eles eram operações pesadas, que atrasavam bastante projetos grandes como o kernel do Linux. Torná-las extremamente rápidas foi um dos objetivos centrais quando o Git foi projetado. A solução foi transformar o branch num ponteiro móvel para um único commit, guardado num arquivo de texto de apenas algumas dezenas de bytes.

Para isso funcionar, o Git espera que você edite o código na linha de trabalho para a qual algum branch aponta, e o ponteiro do branch avança automaticamente a cada novo commit. Trocar de branch significa fazer o HEAD, o ponteiro que indica onde você está, coincidir com esse branch. Por isso, no Git, para onde quer que você vá, acaba sempre empurrado para a ponta do histórico.

Como o Git era o único VCS distribuído que eu conhecia, achava que todos funcionavam assim. Descobrir que esse comportamento é específico do Git, e entender o mecanismo por trás dele, foi o que finalmente me fez entender o que significa dizer que um branch do Git é um ponteiro.

O que acontece com uma bifurcação do histórico sem branch?

Então, o Git pode ter uma bifurcação do histórico que não seja um branch? Criar uma é bem fácil: faça checkout de um commit antigo pelo hash.

$ git checkout 9effb1cc737824d9c14e1a8ecbb725e44ccae104
Note: switching to '9effb1cc737824d9c14e1a8ecbb725e44ccae104'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
⋮
HEAD is now at 9effb1c create b.txt

$ echo '444' > d.txt
$ git add .
$ git commit -m 'create d.txt'
[detached HEAD 46b43c3] create d.txt
 1 file changed, 1 insertion(+)
 create mode 100644 d.txt

O Git faz questão de avisar que agora você está em estado de detached HEAD (HEAD desanexado). Normalmente o HEAD aponta para algum branch. Quando ele aponta diretamente para o hash de um commit específico, isso se chama detached HEAD. Empilhar commits nesse estado é considerado arriscado e é melhor evitar, porque esse histórico acaba assim:

Você não consegue encontrá-lo depois
Ele é tratado como lixo e acaba sendo apagado
Você não consegue compartilhá-lo com ninguém

No Git, os commits só passam a ser rastreáveis por pessoas quando pertencem a um branch ou a uma tag. Os commits feitos em detached HEAD perdem a referência assim que você troca de branch, e não aparecem nem no git log --all. O reflog é a única forma de recuperá-los. Além disso, o sistema os trata como histórico desnecessário e eles ficam sujeitos à coleta de lixo, então, quando o prazo expira, somem de vez. Commits que você mesmo pode perder de vista com facilidade, e que podem sumir a qualquer momento, naturalmente são difíceis de compartilhar com outras pessoas.

Por que o Jujutsu tem bookmarks em vez de branches

Como comentei no começo, o Jujutsu não tem nada chamado “branch” que dê para manipular. Mesmo assim, a palavra “branch” aparece o tempo todo na documentação dele, no sentido literal de bifurcação do histórico. O Jujutsu não tem o conceito de “branch atual” nem nenhum mecanismo próprio para identificar bifurcações do histórico, então “branch” é usado no seu sentido original e literal.

Então, por que o Jujutsu não tem branches como os do Git e do Mercurial? No Git, fazer amend ou rebase de um commit gera um hash completamente novo. Hashes que mudam o tempo todo são difíceis de acompanhar, tanto para o sistema quanto para as pessoas, então um commit precisa pertencer a um branch: um rótulo nomeado e estável que diz em qual linha de trabalho ele está. No Jujutsu, por outro lado, a unidade básica do histórico, o change, tem um change ID imutável , separado do commit ID, que muda sempre que o change é revisado. Não importa quantas vezes você reescreva o conteúdo ou faça rebase, dá para acompanhar um change pelo mesmo ID, então quase não há necessidade de rotular cada linha de trabalho.

Além disso, as bifurcações do histórico sempre aparecem no log como um grafo em arte ASCII. Entre o grafo que você vê no log e as descrições dos changes que formam os nós dele, dá para ver de cara a qual linha de trabalho cada change pertence. E qualquer change que tenha descrição ou que modifique arquivos fica no histórico até você descartá-lo explicitamente.

Como os branches não têm nome, o normal no Jujutsu é trabalhar no equivalente ao detached HEAD do Git. O Jujutsu chama isso de branch anônimo (anonymous branch). O detached HEAD é considerado perigoso, mas os branches anônimos do Jujutsu não têm os dois primeiros problemas que ele tem no Git: “1. Você não consegue encontrá-lo depois” e “2. Ele é tratado como lixo e acaba sendo apagado”. E o “3. Você não consegue compartilhá-lo com ninguém”? É para isso que o Jujutsu oferece os bookmarks.

Um bookmark é um ponteiro nomeado associado a um change. Tanto os bookmarks quanto os branches do Git são ponteiros nomeados, mas, diferente de um branch do Git, um bookmark é apenas uma marcação para compartilhar com outras pessoas ou para você não esquecer de algo, sem relação direta com as bifurcações do histórico. É por isso que você pode colocar vários bookmarks na mesma linha de trabalho, e também por isso que, quando você cria novos changes sobre esse change, um bookmark não avança sozinho como um branch do Git.

O Jujutsu não vê necessidade de dar nome às bifurcações do histórico, nem de apontar uma linha de trabalho divergente inteira só para compartilhar histórico com outras pessoas. É por isso que o Jujutsu tem bookmarks em vez de branches.

Branches anônimos + bookmarks: até onde a evolução dos VCSs chegou

No Git, tanto criar bifurcações do histórico quanto fazer merge delas acontece, basicamente, no nível do branch. E como o Jujutsu, que não tem branches, lida com isso?

No Jujutsu, o comando que cria um change novo, a unidade básica do histórico, é o jj new. Como criar uma bifurcação do histórico? Passe para o jj new o ID de um change que já tem um filho. Como fazer merge de um histórico que divergiu? Passe para o jj new os IDs dos changes que você quer juntar. No Jujutsu, estender o histórico, bifurcá-lo e fazer merge funcionam no nível do change , e, surpreendentemente, tudo é a mesma operação básica: criar um change novo.

Você segue trabalhando assim até um ponto em que faz sentido parar. Hora de abrir um PR. É só agora que você precisa de fato dar um nome a essa linha de trabalho⁴. Coloque um bookmark num change e faça push, e toda a sequência de changes, desde o ponto em que ela saiu da main até esse change, é registrada como um branch no repositório Git remoto, com cada change convertido num commit do Git.

O que você ganha quando a unidade de compartilhamento não está presa a branches? Primeiro, flexibilidade: você pode começar a trabalhar sem decidir um nome nem o que vai compartilhar, e resolver essas questões só quando chegar a hora de compartilhar. Segundo, fica fácil montar uma série de PRs dependentes, algo que ficou bem mais valioso nos últimos tempos. Os stacked pull requests do GitHub, que permitem dividir um PR em unidades pequenas com relações de pai e filho, finalmente ficaram disponíveis para todos em 6 de outubro de 2026⁵, e os bookmarks do Jujutsu deixam muito fácil trabalhar com eles. Para montar stacked PRs com o Git, você cria o primeiro branch com gh stack init, cria um branch filho com gh stack add toda vez que termina uma parte do trabalho e, no fim, faz push e abre os PRs com gh stack submit. É um processo bem trabalhoso e muito dependente de ferramentas específicas. Com o Jujutsu, você coloca bookmarks em ordem na sua linha de trabalho, faz push e roda algo como gh stack link <bookmark1> <bookmark2> <bookmark3>. Só isso. É tão simples que chega a ser anticlimático.

Sem branches, o Jujutsu repensou as operações que o Git tinha construído em torno deles, para que você possa trabalhar em unidades menores e mais flexíveis. Depois de conviver um tempo com um Jujutsu sem branches, finalmente entendi o que são os branches do Git, depois de anos usando-os com uma ideia nebulosa. E aí os conceitos do Jujutsu, tão diferentes dos do Git, começaram a me parecer surpreendentemente racionais. Essa sensação fica ainda mais forte quando você olha a história dos VCSs com certo distanciamento.

Comentei antes que o Mercurial tem um tipo de branch diferente do Git. Mas, como os branches do Mercurial são dados permanentes e globais gravados em cada commit, eles não combinam bem com o desenvolvimento de funcionalidades ou correções de bugs que terminam em poucos dias. Por isso os bookmarks foram adicionados depois, para o trabalho mais leve: marcadores do tipo ponteiro que serviam para repassar o trabalho no push ou para marcar onde você estava trabalhando. Inspirados nos branches do Git, mas independentes dos branches do Mercurial e pensados para o compartilhamento. É daí que vêm os bookmarks do Jujutsu.

O Jujutsu vai um passo além: considera os branches desnecessários para as bifurcações do histórico e simplesmente não os tem. Curiosamente, o Sapling, que a Meta criou a partir de um fork do Mercurial e desenvolveu por conta própria, também não tem branches, mas tem bookmarks. Dá para dizer que “branches anônimos + bookmarks” é um dos pontos a que a evolução do controle de versões chegou, do Git ao Jujutsu, passando pelo Mercurial.

Uma última observação: este post é baseado nas seções “2-4-2. A diferença entre branch e bookmark” e “2-4-3. Trabalhando em branches anônimos” do meu livro, Juju-chu! — Comece seu fluxo de trabalho Jujutsu × IA com jj new.

Juju-chu! — Comece seu fluxo de trabalho Jujutsu × IA com jj new

Um guia prático para adotar Jujutsu (jj) com Claude Code e Codex: snapshots automáticos, operações que podem ser desfeitas e reescrita segura do histórico.

juju-chu.com

Os primeiros capítulos do livro se concentram na diferença entre os modelos mentais do Git e do Jujutsu. Além de branches versus bookmarks, eles explicam com cuidado os outros pontos em que quem está começando costuma tropeçar. Se este post te deu vontade de experimentar o Jujutsu, ou de dar mais uma chance a ele se da primeira vez não engrenou, dê uma olhada.

Footnotes

Livro de código aberto sobre Git, escrito por Scott Chacon e Ben Straub, que também é usado como documentação oficial do Git. Ele pode ser lido gratuitamente online. https://git-scm.com/book/pt-br/v2 ↩
https://git-scm.com/book/pt-br/v2/Ramifica%c3%a7%c3%a3o-Branching-no-Git-Branches-em-Poucas-Palavras#divergent_history ↩
Sigla em inglês de Directed Acyclic Graph (grafo acíclico dirigido): uma estrutura de grafo em que os nós, ligados por arestas com direção, nunca formam um ciclo. ↩
Se você prefere dar um nome logo de início, claro que também dá. Crie um bookmark com jj bookmark create ao começar o trabalho e, antes de fazer push, mova-o para o change desejado com jj bookmark move ou jj bookmark advance. ↩
Stacked pull requests generally available - GitHub Changelog ↩

Jujutsu no tiene un paso para «crear una rama», y así por fin entendí las ramas de Git

Yuka Ooka — Tue, 13 Oct 2026 12:43:00 +0000

¿Jujutsu no tiene ramas?

Cuando empecé a usar Jujutsu después de años de trabajar con Git y acostumbrarme a sus flujos de trabajo, lo primero que me desconcertó fue que no había ninguna rama a la que perteneciera mi trabajo actual. Si empiezas con Git, te enseñan la rutina: antes de ponerte a trabajar en serio, crea una rama. Incluso en un proyecto personal en el que te saltas ese paso, al menos estás en la rama main.

Sin embargo, la documentación oficial y el popular tutorial se lanzan directamente al trabajo. Nadie crea una rama ni se cambia a otra. De hecho, por más que busqué, no encontré en Jujutsu nada llamado «rama» (branch) que se pudiera manipular. En su lugar hay algo llamado bookmark , que se mapea como una rama al trabajar con Git. Y aun así, un bookmark no es lo mismo que una rama. No entendía nada.

Pero después de hacer push de mi trabajo en Jujutsu y abrir PRs con él unas cuantas veces siguiendo las guías, se me ocurrió algo: quizá Git y Jujutsu simplemente se refieren a cosas distintas con la palabra «rama». Con esa idea en mente, volví a leer el capítulo sobre ramas de Pro Git¹ y la página sobre bookmarks de la documentación de Jujutsu, y por fin todo encajó. Una rama de Git no es una «rama» en sentido literal, y hay buenas razones para que Jujutsu llame «bookmark» a su equivalente.

Qué significa realmente «una rama de Git es un puntero»

Entonces, ¿qué es exactamente una rama de Git? La sección 3.1 de Pro Git describe las ramificaciones así:

Cuando hablamos de ramificaciones, significa que tú has tomado la rama principal de desarrollo (master) y a partir de ahí has continuado trabajando sin seguir la rama principal de desarrollo.

Si sigues leyendo, encuentras esto:

Una rama Git es simplemente un apuntador móvil apuntando a una de esas confirmaciones.

[…]

¿Qué sucede cuando creas una nueva rama? Bueno…, simplemente se crea un nuevo apuntador para que lo puedas mover libremente.

«Una rama es un puntero» (o apuntador, en inglés pointer). Si llevas un tiempo usando Git, seguro que has oído esa frase. Me da algo de vergüenza admitirlo, pero nunca me dijo gran cosa, y durante años usé las ramas por pura intuición (al tanteo). Ahora entiendo por qué. La explicación se apoya en varias premisas que nadie menciona, y a quienes tuvieron Git como primer VCS no les dice mucho. La documentación oficial de Git y los libros clásicos los escribieron veteranos que conocían bien otros sistemas de control de versiones, y es fácil que pasen por alto que quienes empezaron con Git no comparten esas premisas.

¿Qué hace falta saber, entonces, para que «una rama es un puntero» tenga sentido? Lo primero es que, en Git, una rama no es la bifurcación del historial en sí. Para distinguir ambas cosas, Pro Git usa expresiones como «el historial diverge» (divergent history) para referirse a la bifurcación misma².

La mayoría de los VCS distribuidos representan el historial como un DAG³ y no como un árbol, así que las bifurcaciones y las fusiones se expresan por completo dentro del grafo. En lo que se diferencian los VCS es en el mecanismo que le dan al usuario para ver y manipular esas bifurcaciones, y la mayoría llama «rama» a ese mecanismo. En Mercurial, que apareció más o menos al mismo tiempo que Git, una rama es un metadato que queda incrustado de forma permanente en cada commit de una línea del historial. Git, en cambio, usa un puntero por cada línea del historial, y cada uno apunta a un solo commit.

¿Todavía no queda claro? Pasemos a la segunda premisa. Lo que distingue a Git de otros VCS es que, estés donde estés, siempre te lleva automáticamente a la punta del historial. En los VCS anteriores, crear ramas y cambiar de una a otra eran operaciones pesadas que ralentizaban seriamente proyectos grandes como el kernel de Linux. Hacerlas rapidísimas fue uno de los objetivos clave al diseñar Git. La solución fue convertir la rama en un puntero móvil a un solo commit, guardado en un archivo de texto de apenas unas decenas de bytes.

Para que eso funcione, Git espera que edites el código en la línea de trabajo a la que apunta alguna rama, y el puntero de la rama avanza automáticamente con cada nuevo commit. Cambiar de rama significa hacer que HEAD, el puntero que indica dónde estás, coincida con esa rama. Por eso en Git, vayas adonde vayas, siempre terminas en la punta más reciente del historial.

Como Git era el único VCS distribuido que conocía, daba por hecho que así funcionaban todos. Descubrir que ese comportamiento es propio de Git, y entender el mecanismo que hay detrás, fue lo que por fin me permitió entender qué significa que una rama de Git sea un puntero.

¿Qué pasa con una bifurcación del historial sin rama?

Entonces, ¿puede haber en Git una bifurcación del historial que no sea una rama? Crear una es muy fácil: haz checkout de un commit anterior usando su hash.

$ git checkout 9effb1cc737824d9c14e1a8ecbb725e44ccae104
Note: switching to '9effb1cc737824d9c14e1a8ecbb725e44ccae104'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
⋮
HEAD is now at 9effb1c create b.txt

$ echo '444' > d.txt
$ git add .
$ git commit -m 'create d.txt'
[detached HEAD 46b43c3] create d.txt
 1 file changed, 1 insertion(+)
 create mode 100644 d.txt

Git se toma la molestia de advertirte que ahora estás en estado de detached HEAD (HEAD desacoplado). Normalmente HEAD apunta a alguna rama. Cuando, en cambio, apunta directamente al hash de un commit concreto, se dice que HEAD está desacoplado. Acumular commits en este estado se considera arriesgado y conviene evitarlo, porque ese historial termina así:

No lo puedes encontrar después
Se trata como basura y termina borrándose
No lo puedes compartir con nadie

En Git, los commits solo se vuelven rastreables para las personas cuando pertenecen a una rama o a un tag. Los commits que haces con HEAD desacoplado pierden su referencia en cuanto cambias de rama, y ni siquiera aparecen en git log --all. El reflog es la única forma de recuperarlos. Además, el sistema los considera historial innecesario y quedan expuestos a la recolección de basura, así que, una vez vencido el plazo, desaparecen para siempre. Si son commits que tú mismo puedes perder de vista con facilidad y que pueden desaparecer en cualquier momento, difícilmente se pueden compartir con otras personas.

Por qué Jujutsu tiene bookmarks en lugar de ramas

Como dije al principio, Jujutsu no tiene nada llamado «rama» que se pueda manipular. Aun así, la palabra «branch» aparece por todas partes en su documentación, con su sentido literal de bifurcación del historial. Jujutsu no tiene el concepto de «rama actual» ni ningún mecanismo específico para identificar las bifurcaciones del historial, así que «branch» se usa en su sentido original y literal.

Entonces, ¿por qué Jujutsu no tiene ramas como las de Git o Mercurial? En Git, hacer amend o rebase de un commit le da un hash completamente nuevo. Los hashes que cambian constantemente son difíciles de seguir, tanto para el sistema como para las personas, así que un commit necesita pertenecer a una rama: una etiqueta con nombre, estable, que indica en qué línea de trabajo está. En Jujutsu, en cambio, la unidad básica del historial, el change, tiene un change ID inmutable , distinto de su commit ID, que cambia cada vez que se revisa el change. Sin importar cuántas veces reescribas su contenido o le hagas rebase, puedes seguir un change con el mismo ID, así que no hace mucha falta etiquetar cada línea de trabajo.

Además, las bifurcaciones del historial siempre se muestran en el log como un grafo en arte ASCII. Entre el grafo que ves en el log y las descripciones de los changes que forman sus nodos, salta a la vista a qué línea de trabajo pertenece cada change. Y cualquier change que tenga descripción o que modifique archivos se queda en el historial hasta que lo descartes explícitamente.

Como las ramas no tienen nombre, en Jujutsu lo normal es trabajar en el equivalente al HEAD desacoplado de Git. Jujutsu lo llama rama anónima (anonymous branch). El HEAD desacoplado se considera peligroso, pero las ramas anónimas de Jujutsu no tienen los dos primeros problemas que ese estado tiene en Git: «1. No lo puedes encontrar después» y «2. Se trata como basura y termina borrándose». ¿Y qué pasa con «3. No lo puedes compartir con nadie»? Para eso Jujutsu ofrece los bookmarks.

Un bookmark es un puntero con nombre asociado a un change. Tanto los bookmarks como las ramas de Git son punteros con nombre, pero, a diferencia de una rama de Git, un bookmark es solo una marca para compartir con otras personas o para no olvidarte de algo, sin relación directa con las bifurcaciones del historial. Por eso puedes poner varios bookmarks en la misma línea de trabajo, y también por eso, cuando creas nuevos changes sobre ese change, un bookmark no avanza por sí solo como lo hace una rama de Git.

Jujutsu no ve la necesidad de ponerles nombre a las bifurcaciones del historial, ni de señalar una línea de trabajo divergente completa solo para compartir historial con otras personas. Por eso Jujutsu tiene bookmarks en lugar de ramas.

Ramas anónimas + bookmarks: hacia dónde ha llegado la evolución de los VCS

En Git, tanto crear bifurcaciones del historial como fusionarlas se hace, en principio, a nivel de rama. ¿Y cómo lo resuelve Jujutsu, que no tiene ramas?

En Jujutsu, el comando que crea un change nuevo, la unidad básica del historial, es jj new. ¿Cómo se crea una bifurcación del historial? Pasándole a jj new el ID de un change que ya tiene un hijo. ¿Cómo se fusiona un historial que diverge? Pasándole a jj new los IDs de los changes que quieres fusionar. En Jujutsu, extender el historial, bifurcarlo y fusionarlo se hace a nivel de change , y, sorprendentemente, todo es la misma operación básica: crear un change nuevo.

Sigues trabajando así hasta un punto en el que tiene sentido parar. Es hora de abrir un PR. Es justo en este punto donde necesitas ponerle nombre a esa línea de trabajo⁴. Pones un bookmark en un change, haces push, y toda la serie de changes, desde donde se separó de main hasta ese change, queda registrada como una rama en el repositorio Git remoto, con cada change convertido en un commit de Git.

¿Qué se gana cuando la unidad para compartir no está atada a las ramas? En primer lugar, flexibilidad: puedes empezar a trabajar sin decidir un nombre ni qué vas a compartir, y resolver esas cuestiones solo cuando llegue el momento de compartir. En segundo lugar, facilita armar una serie de PRs dependientes, algo que últimamente se ha vuelto mucho más valioso. Los stacked pull requests de GitHub, que permiten dividir un PR en unidades pequeñas con relaciones padre-hijo, por fin pasaron a disponibilidad general el 6 de octubre de 2026⁵, y con los bookmarks de Jujutsu es muy fácil trabajar con ellos. Para armar stacked PRs con Git, creas la primera rama con gh stack init, creas una rama hija con gh stack add cada vez que terminas una parte del trabajo y, al final, haces push y abres los PRs con gh stack submit. Es un proceso bastante tedioso y dependiente de herramientas específicas. Con Jujutsu, pones bookmarks en orden sobre tu línea de trabajo, haces push y ejecutas algo como gh stack link <bookmark1> <bookmark2> <bookmark3>. Eso es todo. Es casi anticlimático de lo fácil que resulta.

Al no tener ramas, Jujutsu replanteó las operaciones que Git había construido en torno a ellas, de modo que puedes trabajar en unidades más pequeñas y flexibles. Después de convivir un tiempo con un Jujutsu sin ramas, por fin entendí qué son las ramas de Git, después de años de usarlas con una idea vaga. Y entonces los conceptos de Jujutsu, tan distintos de los de Git, empezaron a parecerme sorprendentemente lógicos. Esa sensación se vuelve aún más fuerte cuando tomas distancia y miras la historia de los VCS.

Ya mencioné que Mercurial tiene un tipo de rama distinto del de Git. Pero como las ramas de Mercurial son datos permanentes y globales incrustados en cada commit, no encajan bien con el desarrollo de funcionalidades o las correcciones de bugs que se terminan en pocos días. Por eso más tarde se agregaron los bookmarks para el trabajo liviano: marcas de tipo puntero que servían para pasar el trabajo al hacer push o para señalar dónde estabas trabajando. Inspirados en las ramas de Git, pero independientes de las ramas de Mercurial y pensados para compartir. De ahí vienen los bookmarks de Jujutsu.

Jujutsu va un paso más allá: considera que las ramas son innecesarias para las bifurcaciones del historial y directamente no las tiene. Curiosamente, Sapling, que Meta creó a partir de un fork de Mercurial y desarrolló por su cuenta, tampoco tiene ramas, pero sí bookmarks. Se podría decir que «ramas anónimas + bookmarks» es uno de los destinos a los que ha llegado la evolución del control de versiones, de Git a Jujutsu pasando por Mercurial.

Una última aclaración: este artículo se basa en las secciones «2-4-2. La diferencia entre branch y bookmark» y «2-4-3. Trabajar en branches anónimas» de mi libro, Juju-chu! —Comienza tu flujo de trabajo Jujutsu × IA con jj new.

Juju-chu! —Comienza tu flujo de trabajo Jujutsu × IA con jj new

Una guía práctica para adoptar Jujutsu (jj) junto a Claude Code y Codex: snapshots automáticos, operaciones que siempre se pueden deshacer y una reescritura del historial que es segura.

juju-chu.com

Los primeros capítulos del libro se centran en la diferencia entre los modelos mentales de Git y de Jujutsu. Además de las ramas frente a los bookmarks, explican con cuidado los otros puntos en los que suelen tropezar quienes empiezan. Si este artículo te dio ganas de probar Jujutsu, o de darle otra oportunidad después de que la primera vez no te convenciera, échale un vistazo.

Footnotes

Libro de código abierto sobre Git escrito por Scott Chacon y Ben Straub, que también se usa como documentación oficial de Git. Se puede leer gratis en línea. https://git-scm.com/book/es/v2 ↩
https://git-scm.com/book/es/v2/Ramificaciones-en-Git-%C2%BFQu%C3%A9-es-una-rama%3F#rdivergent_history ↩
Siglas en inglés de Directed Acyclic Graph (grafo acíclico dirigido): una estructura de grafo en la que los nodos, unidos por aristas con dirección, nunca forman un ciclo. ↩
Si prefieres ponerle nombre desde el principio, por supuesto también puedes hacerlo. Crea un bookmark con jj bookmark create al empezar a trabajar y, antes de hacer push, muévelo al change que corresponda con jj bookmark move o jj bookmark advance. ↩
Stacked pull requests generally available - GitHub Changelog ↩

Jujutsu Has No “Create a Branch” Step, and That Finally Made Git Branches Click

Yuka Ooka — Tue, 13 Oct 2026 12:40:00 +0000

Jujutsu Has No Branches?

When I started using Jujutsu with a brain trained by years of Git workflows, the first thing that threw me was that there was no branch for my current work to belong to. Every Git beginner learns the drill: before you do any real work, create a branch. Even on a casual side project where you skip that step, you’re at least on the main branch.

Yet the official docs and the well-known tutorial just dive straight into the work. Nobody creates a branch or switches to one. In fact, no matter where I looked, I couldn’t find anything in Jujutsu called a “branch” that you could actually operate on. Instead there’s this thing called a bookmark , which gets mapped to a branch when you work with Git. And yet a bookmark is apparently not the same thing as a branch. I had no idea what was going on.

After I’d pushed my Jujutsu work and opened PRs from it a few times by following the guides, though, something occurred to me: maybe Git and Jujutsu simply mean different things by the word “branch.” With that in mind, I reread the branching chapter of Pro Git¹ and the bookmarks page in the Jujutsu docs, and it finally clicked. A Git branch isn’t a “branch” in the literal sense, and there’s good reason Jujutsu calls its counterpart a “bookmark.”

What “A Git Branch Is a Pointer” Actually Means

So what exactly is a Git branch? Section 3.1 of Pro Git, cited above, describes branching this way:

Branching means you diverge from the main line of development and continue to do work without messing with that main line.

Read a little further and you’ll find this:

A branch in Git is simply a lightweight movable pointer to one of these commits.

[…]

What happens when you create a new branch? Well, doing so creates a new pointer for you to move around.

“A branch is a pointer.” If you’ve used Git for any length of time, you’ve heard that line. Embarrassingly, it never meant much to me, and for years I used branches by feel. I can see why now. The explanation rests on several unstated assumptions, and for people whose first VCS was Git, it doesn’t tell you much. Git’s official documentation and the classic books were written by veterans who knew other version control systems well, and it’s easy for them to overlook that people who started with Git don’t share those assumptions.

So what do you need to know before “a branch is a pointer” makes sense? The first thing is that in Git, a branch is not the split in history itself. To keep the two apart, Pro Git uses phrases like “divergent history” for the split itself².

Most distributed VCSs represent history as a DAG³ rather than a tree, so splits and merges are expressed entirely within the graph. Where VCSs differ is in the mechanism they give users to see and work with those splits, and most of them call that mechanism a “branch.” In Mercurial, which appeared around the same time as Git, a branch is metadata permanently embedded in every commit on a given line of history. Git, by contrast, uses one pointer per line of history, each pointing to a single commit.

Still fuzzy? Then let’s move on to the second assumption. What sets Git apart from other VCSs is that wherever you are, you always get pushed to the tip of history automatically. In earlier VCSs, creating and switching branches were heavy operations that seriously slowed down large projects like the Linux kernel. Making them blazingly fast was a key goal when Git was designed. The answer was to make a branch a movable pointer to a single commit, stored in a text file of just a few dozen bytes.

To make that work, Git expects you to edit code on the line of work some branch points to, and the branch pointer automatically moves to each new commit. Switching branches means making HEAD, the pointer to where you currently are, line up with that branch. So in Git, wherever you go, you always end up pushed to the tip of history.

Since Git was the only distributed VCS I knew, I assumed that’s simply how distributed VCSs work. Learning that this behavior is specific to Git, and understanding the machinery behind it, finally brought “a Git branch is a pointer” into focus.

What Happens to a Split in History Without a Branch?

So can Git have a split in history that isn’t a branch? It’s actually easy to make one: check out a past commit by its hash.

$ git checkout 9effb1cc737824d9c14e1a8ecbb725e44ccae104
Note: switching to '9effb1cc737824d9c14e1a8ecbb725e44ccae104'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
⋮
HEAD is now at 9effb1c create b.txt

$ echo '444' > d.txt
$ git add .
$ git commit -m 'create d.txt'
[detached HEAD 46b43c3] create d.txt
 1 file changed, 1 insertion(+)
 create mode 100644 d.txt

Git goes out of its way to tell you that you’re now in a detached HEAD state. Normally HEAD points to some branch. When HEAD points directly to a specific commit hash instead, that’s called detached HEAD. Stacking commits in this state is considered risky and best avoided, because that history ends up like this:

You can’t find it later
It’s treated as garbage and eventually deleted
You can’t share it with others

In Git, commits only become traceable by humans once they belong to a branch or a tag. Commits you make in detached HEAD lose their reference the moment you switch branches, and they don’t show up even in git log --all. The reflog is your only way to get them back. The system also treats them as unneeded history and makes them eligible for garbage collection, so once the expiry period passes, they’re gone for good. Commits that you can easily lose track of yourself, and that could vanish at any time, are naturally hard to share with anyone else.

Why Jujutsu Has Bookmarks Instead of Branches

As I mentioned at the start, Jujutsu has nothing called a “branch” that you can operate on. Yet the word “branch” shows up all over the Jujutsu docs, in its literal sense of a split in history. Jujutsu has no concept of a “current branch,” and no dedicated mechanism for identifying splits in history, so “branch” is used in its plain, original meaning.

So why doesn’t Jujutsu have branches like Git and Mercurial do? In Git, amending or rebasing a commit gives it an entirely new hash. Hashes that keep changing are hard for both the system and humans to follow, so a commit needs to belong to a branch: a stable named label that says which line of work it’s on. In Jujutsu, on the other hand, the basic unit of history, the change, carries an immutable change ID separate from its commit ID, which changes whenever the change is revised. However many times you rewrite its contents or rebase it, you can track a change by the same ID, so there’s little need to label every line of work.

Splits in history are also always visualized in the log as an ASCII-art graph. Between the tree graph you can see in the log and the descriptions of the changes that form its nodes, it’s obvious at a glance which line of work each change belongs to. And any change that has a description or modifies files stays in your history until you explicitly abandon it.

With no named branches, the normal way to work in Jujutsu is in the equivalent of Git’s detached HEAD. Jujutsu calls this an anonymous branch. Detached HEAD is considered dangerous, but Jujutsu’s anonymous branches don’t have the first two problems it has in Git: “1. You can’t find it later” and “2. It’s treated as garbage and eventually deleted.” What about “3. You can’t share it with others”? That’s what Jujutsu provides bookmarks for.

A bookmark is a named pointer attached to a change. Both are named pointers, but unlike a Git branch, a bookmark is purely a marker for sharing with others or for reminding yourself, with no direct connection to splits in history. That’s why you can put multiple bookmarks on the same line of work, and also why, when you add new history on top, a bookmark doesn’t automatically move forward the way a Git branch does.

Jujutsu sees no need to name splits in history, or to designate an entire diverging line of work just to share history with others. That’s why Jujutsu has bookmarks instead of branches.

Anonymous Branches + Bookmarks: Where VCS Evolution Landed

In Git, both creating splits in history and merging them basically happen at the branch level. So how does Jujutsu, with no branches, handle them?

In Jujutsu, the command that creates a new change, the basic unit of history, is jj new. How do you create a split in history? Pass jj new the ID of a change that already has a child. How do you merge diverging history? Pass jj new the IDs of the changes you want to merge. In Jujutsu, extending history, branching, and merging all work at the level of the change , and remarkably, they’re all the same basic operation: creating a new change.

You keep working like this until you reach a stopping point. Time to open a PR. This is the first time you actually need to give that line of work a name⁴. Set a bookmark on a change and push it, and the whole series of changes from where it split off from main up to that change gets registered in the remote Git repository as a branch, with each change mapped to a Git commit.

So what do you gain when the unit of sharing isn’t tied to branches? First, flexibility: you can start working without deciding on a name or on what to share, and settle those questions only when it’s time to share. Second, it makes a series of dependent PRs easy to build, which has recently become a lot more valuable. GitHub’s stacked pull requests, which let you split a PR into small units with parent-child relationships, finally became generally available on October 6, 2026⁵, and Jujutsu bookmarks make them very easy to work with. To build stacked PRs with Git, you create the first branch with gh stack init, create a child branch with gh stack add each time you finish a chunk of work, and finally push and open the PRs with gh stack submit. It’s a fairly involved process that leans heavily on dedicated tooling. With Jujutsu, you put bookmarks on your line of work in order, push, and run something like gh stack link <bookmark1> <bookmark2> <bookmark3>. That’s it. It’s almost anticlimactic.

Without branches, Jujutsu has rethought the operations Git built around branches, so you can work in smaller and more flexible units. After living with branchless Jujutsu for a while, I finally understood what Git branches are, after years of using them with only a fuzzy idea. And then Jujutsu’s concepts, so different from Git’s, started to look surprisingly rational. That feeling gets even stronger when you step back and look at the history of VCSs.

I mentioned earlier that Mercurial has a different kind of branch from Git’s. But since Mercurial branches are permanent, global data embedded in every single commit, they’re a poor fit for feature work or bug fixes that wrap up in a few days. So bookmarks were added later for lightweight work: pointer-style markers you could use to hand off work on push, or to mark where you’re currently working. Modeled on Git branches, yet independent of branches and built for sharing. That’s where Jujutsu’s bookmarks come from.

Jujutsu takes this one step further: it treats branches as unnecessary for splits in history and doesn’t have them as a feature at all. Interestingly, Sapling, which Meta forked from Mercurial and developed on its own, also has bookmarks and no branches. You could say that “anonymous branches + bookmarks” represents one destination in the evolution of version control, from Git through Mercurial to Jujutsu.

One last note: this post is based on sections “2-4-2. The Difference Between Branches and Bookmarks” and “2-4-3. Working on Anonymous Branches” 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 early chapters of the book focus on the difference between Git’s and Jujutsu’s mental models. Besides branches versus bookmarks, they carefully walk through the other places where newcomers tend to stumble. If this post made you want to try Jujutsu, or to give it another shot after bouncing off it once, take a look.

Footnotes

An open-source book on Git by Scott Chacon and Ben Straub, also used as Git’s official documentation. It’s available free online. https://git-scm.com/book/en/v2 ↩
https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell#divergent_history ↩
Short for Directed Acyclic Graph: a graph structure in which nodes connected by directed edges never form a cycle. ↩
If you’d rather name things up front, you can of course do that too. Create a bookmark with jj bookmark create when you start working, then move it to the target change with jj bookmark move or jj bookmark advance before you push. ↩
Stacked pull requests generally available - GitHub Changelog ↩

Por que continuo escolhendo o Jujutsu mesmo com a IA cuidando do Git

Yuka Ooka — Tue, 06 Oct 2026 12:48:00 +0000

“Se um agente de IA já cuida do Git para você, por que aprender outro sistema de controle de versões, como o Jujutsu?”

Essa foi a objeção mais comum ao meu último post, 15 anos de Git e depois Jujutsu: por que não consigo mais voltar. É uma dúvida legítima, e também interessante, então este post é a minha resposta.

Concordo que o controle de versões do dia a dia é trabalho para um agente de IA. É exatamente assim que eu trabalho. A diferença é que os comandos que meus agentes executam são do Jujutsu, não do Git. Depois de experimentar os dois jeitos, estou convencida de que, mesmo com a IA no comando, o Jujutsu oferece uma experiência de desenvolvimento muito melhor, e de que o tempo investido para aprendê-lo se paga rapidamente.

Antes de apresentar meus argumentos, vale esclarecer logo uma dúvida óbvia: a IA consegue mesmo lidar com o Jujutsu? Testei com Opus, GPT, Gemini e outros. Os modelos mais recentes já conhecem nativamente os conceitos básicos e os principais comandos do Jujutsu, e conseguem cuidar das operações do dia a dia sem carregar nenhuma skill extra. Dito isso, o Jujutsu não está tão integrado às ferramentas dos agentes quanto o Git, então é preciso alguma configuração para impedir que o agente volte ao Git sem avisar e para ensinar a ele um fluxo de trabalho adequado ao Jujutsu. Esta é a configuração que eu uso.

A cerimônia do commit no Git versus os changes sem atrito do Jujutsu

No Git, a unidade básica do histórico é o commit. O fluxo padrão é assim: você edita arquivos na working tree, escolhe os que quer e os adiciona ao índice, depois escreve uma mensagem e cria um commit. Só então algo entra no histórico. Um commit foi pensado para ser um produto acabado, algo feito com cuidado, e é por isso que o Git oferece o índice como staging area. Editar um arquivo e registrar essas alterações no histórico exige uma sequência longa e rígida de passos. É quase um ritual.

Então, mesmo quando você entrega o Git a uma IA, continua terminando cada tarefa com o pedido “faça o commit disso”. Peça qualquer operação no histórico no meio de uma tarefa e lá vem a troca de sempre: “Há alterações sem commit. Devo guardá-las no stash ou fazer o commit primeiro?”. Cada rodada talvez leve só meio minuto, mas acontece o tempo todo, e tudo isso vai somando. Há também um custo cognitivo, pago tanto por você quanto pela IA, mesmo que você não perceba.

No Jujutsu, a unidade básica do histórico é o change. Quando você inicializa um repositório, começa em um change vazio. Cada edição que você faz ali é salva, conforme você trabalha, como uma nova revisão desse change¹. Você pode adicionar uma descrição, o equivalente no Jujutsu a uma mensagem de commit, quando quiser. Um change nunca tem um momento em que fica oficialmente “pronto”². Quando termina o trabalho, você simplesmente segue em frente.

Isso significa que, quando uma IA opera o Jujutsu por você, basta deixar uma instrução fixa: começar cada tarefa em um change novo, com uma descrição³. A partir daí, você só diz “crie a funcionalidade X”, e o histórico fica dividido em unidades razoáveis que acompanham o fluxo do trabalho. Chega de “faça o commit disso” no fim de cada tarefa, e chega de ter que arrumar a cópia de trabalho antes de uma operação no histórico.

O Jujutsu é compatível com o Git, mas não existe índice entre o seu diretório de trabalho e o seu repositório local. Além disso, o estado do seu diretório de trabalho é o ponto atual do histórico (o Jujutsu chama isso de “working copy as a commit”, a cópia de trabalho como commit). No Git, tanto pessoas quanto a IA precisam acompanhar três estados para cada alteração em um arquivo. No Jujutsu, normalmente há só um. Só depois de migrar percebi quanto esforço mental extra eu gastava para me adaptar ao jeito do Git de fazer as coisas, e como todo aquele controle era estressante.

Alguns de vocês vão dizer que isso não incomoda nem um pouco. Tudo bem. Muita gente realmente não se importa de vestir terno e chegar ao escritório às 8h30 todas as manhãs. Mas imagine sair disso para um emprego sem código de vestimenta, com horário flexível e trabalho remoto até três dias por semana, e achar tudo tão confortável que não daria mais para voltar. Foi isso que senti com a mudança.

O Jujutsu facilita desfazer os erros da IA

Pessoas erram, e a IA também. Ainda vejo, de vez em quando, relatos de agentes de IA que apagaram arquivos em que alguém estava trabalhando, sem nenhum jeito de recuperá-los. Peça a um agente para resolver um conflito e não é raro receber um resultado que passa nos testes, mas está semanticamente quebrado. E como as instruções aos agentes são dadas em linguagem natural, um prompt nem sempre transmite bem a sua intenção, então muitas vezes você não vai ficar satisfeito com o que recebe.

Quando a IA executa comandos do Git como parte do trabalho, recuperar-se de um resultado ruim fica muito mais difícil. O Git não tem como voltar o repositório inteiro ao estado em que estava antes de uma determinada operação. Como mencionei, o Git guarda estado em vários lugares: a working tree, o índice, o stash e os commits, e cada um tem sua própria forma de proteção, quando existe alguma. Rebase, amend e squash não modificam os commits existentes. Eles criam commits novos e movem o branch para eles, de modo que os originais deixam de ser referenciados por qualquer branch. Eles continuam no reflog, mas encontrar depois a entrada certa, enterrada no meio de todo o resto, é uma verdadeira dor de cabeça.

Para compensar o fato de o Git não salvar alterações sem commit, o Claude Code oferece o comando /rewind, que volta o código a um ponto anterior junto com a conversa. Mas ele não combina bem com um agente que executa comandos do Git. Seus arquivos voltam, mas o estado do Git não, então de repente o git status mostra uma pilha de alterações que você nunca quis, e lá vai você arrumar o histórico de novo. E o que tiver sido alterado por comandos do shell, por você ou por outros agentes rodando em paralelo não é revertido de jeito nenhum.

Se você percebe um erro na hora, ainda está numa boa. Mas o mais comum é ele aparecer depois, quando você roda os testes após continuar trabalhando ou quando revisa as coisas dias mais tarde. A essa altura, fica muito mais difícil desembaraçar tudo. Mais operações se acumularam em cima da errada e, mesmo que você mergulhe de cabeça no reflog, nada garante que uma longa série de passos delicados vai resolver. Pior: o Git não oferece nenhum jeito de desfazer a própria tentativa de recuperação. Uma IA que tenta uma correção atrás da outra para sair do buraco pode facilmente piorar as coisas.

O Jujutsu resolve quase tudo isso. Como regra geral, o resultado de qualquer comando jj pode ser revertido com jj undo, e o próprio undo pode ser desfeito com jj redo. Isso é possível porque o Jujutsu mantém, separado do log normal, um registro de cada operação que altera o repositório: o operation log. Cada entrada do operation log está ligada a um snapshot do repositório como ele ficou ao final daquela operação. Você pode restaurar os arquivos para esse estado, ou reverter só o efeito daquela operação, mantendo tudo o que veio depois.

Cada comando jj que uma IA executa durante uma longa sessão de tentativa e erro também vai parar no operation log. Quando algo dá errado, você pode repassar tudo o que a IA fez, identificar a causa e voltar ao estado logo antes de as coisas desandarem.

Além disso, ao contrário do hash de um commit do Git, que muda toda vez que você edita o commit, o change ID do Jujutsu continua o mesmo, não importa quantas vezes o change seja revisado. Você pode consultar o histórico de revisões de um change no evolution log e, com um pouco de garimpo, encontrar uma versão anterior e restaurar seu conteúdo. Usando a data e a hora ou o diff como referência, dá até para se recuperar de uma resolução de conflito malfeita de vários dias atrás e refazê-la.

Cada edição é salva no histórico conforme você trabalha. O operation log e o evolution log permitem encontrar onde as coisas deram errado e voltar a esse ponto. E se a própria recuperação der errado, jj undo e jj redo deixam você tentar de novo na mesma hora. É um nível de segurança que o Git simplesmente não oferece, e é exatamente por isso que, com o Jujutsu, consigo entregar o controle de versões a uma IA com mais tranquilidade, e com mais ousadia, do que jamais consegui com o Git.

Por que um histórico limpo importa mais na era da programação com IA

Outro comentário que se destacou no meu último post foi “não faço questão de manter o histórico limpo, então não vejo sentido no Jujutsu”. O raciocínio parece ser que, mesmo que o histórico esteja uma bagunça, basta pedir à IA para encontrar o que você precisa. Mas será que é assim mesmo? Eu diria que é o contrário: justamente porque, com a IA, escrevemos e lemos menos código, um histórico limpo importa mais do que nunca.

Os agentes de programação melhoraram tanto que muitos desenvolvedores hoje mal escrevem código e também não leem cada linha que a IA gera. Mesmo assim, eles continuam zelando pela qualidade do que vai para produção, seja pedindo a um agente com outro modelo que revise o trabalho, seja conferindo pessoalmente as partes críticas, como mudanças em estruturas de dados. Se você consegue rastrear direto no histórico o que mudou, por que e do que depende, tudo isso fica mais rápido e com menos erros. Justamente porque ninguém está revisando cada linha, seu histórico de commits precisa funcionar como o sumário do código , para que você encontre as partes que importam. Uma sequência de commits gigantes sem intenção clara obriga a IA a carregar contexto irrelevante toda vez, o que gasta tokens e pode prejudicar a qualidade do trabalho dela.

No início de cada sessão, um agente costuma olhar primeiro os diffs significativos mais recentes, antes do diretório de trabalho como um todo. Enfie “uma correção de bug + uma atualização de dependências + conteúdo sem relação + uma refatoração que não tem nada a ver” em um único commit, e o agente se confunde. Organize commits de tamanho razoável e com intenção clara, numa ordem que reflita a relação de causa e efeito, e até um prompt curto vai dar ao agente o contexto de que ele precisa para a próxima tarefa.

E mesmo que você quase não leia o código gerado pela IA durante o desenvolvimento, um incidente vai obrigar você a lê-lo com atenção. A primeira pergunta diante de uma queda em produção é “quando e onde entrou o código problemático?”. Quando cada minuto conta, um histórico de commits semanticamente coerentes ajuda você a localizar o problema rapidamente.

A programação com IA também criou um problema novo ao disparar a produtividade: os PRs ficam enormes → fica difícil revisá-los → PRs sem merge se acumulam à espera de revisão. Agora até equipes de poucas pessoas caem nesse ciclo. Gigantes de tecnologia como Google e Meta lidam com esse problema há mais de uma década, e a resposta delas tem sido “dividir os PRs em unidades pequenas que dependem umas das outras”. Suponha que você normalmente enviaria uma funcionalidade inteira como um único PR. Em vez disso, você cria quatro PRs: “1. alterações na camada de modelo”, “2. alterações nas tarefas agendadas”, “3. alterações na API do servidor” e “4. alterações no frontend web”. Depois, empilha esses PRs na ordem 1 → 2 → 3 → 4. Cada um pode ser revisado, aprovado e receber merge separadamente, mas um PR só pode receber merge depois que os PRs abaixo dele na pilha (no caso do 3, o 1 e o 2) já tiverem entrado. Essas empresas incorporaram esse fluxo às suas ferramentas e passaram a usá-lo no desenvolvimento do dia a dia.

PRs pequenos e com um papel lógico claro facilitam a vida de quem revisa, e fica mais fácil identificar quais você precisa revisar. As alterações no branch de um PR mais abaixo na pilha se propagam automaticamente para os branches acima dele, com o rebase feito pelas ferramentas. E, graças às dependências, você pode começar com segurança a próxima parte do trabalho enquanto o primeiro PR ainda espera revisão. É isso que se costuma chamar de stacked diffs ou stacked PRs. Graphite, GitButler, GitLab e outros vêm oferecendo suporte há anos. E, em julho de 2026, o GitHub finalmente lançou os stacked PRs em versão prévia pública. Com o maior player a bordo, tudo indica que a tendência vai ganhar força.

Entre a popularização dos monorepos e o impacto dos agentes de IA, a demanda por stacked PRs está crescendo não só nas grandes empresas, mas também nas pequenas e médias. Quando os stacked PRs passam a fazer parte do jeito de trabalhar de uma equipe, acertar as unidades do histórico e a ordem delas vira parte do trabalho de cada desenvolvedor. PRs em que antes cabia de tudo agora precisam ser divididos pelo papel lógico, com dependências entre eles. E o Jujutsu torna isso fácil e seguro.

Pense em dividir um commit gigante em unidades com sentido. É uma tarefa difícil, até para a IA. No Git, você provavelmente faria git reset HEAD^ para devolver o commit inteiro à working tree e depois repetiria o ciclo de adicionar ao índice e fazer commit, pedaço por pedaço. Se você errar no meio do caminho, recuperar-se significa descobrir exatamente até onde a divisão chegou e quais edições ficaram onde, o que já é uma dor de cabeça por si só. E se o commit que você quer dividir for antigo, prepare-se para a emoção de encadear rebases com o HEAD desanexado (detached HEAD). No Jujutsu, você passa os arquivos para jj split -m <description> e pronto. Se errar, desfaz e tenta de novo. Quando quem faz isso é uma IA, a divisão é por arquivo, mas uma pessoa operando o Jujutsu pode usar jj split -i para dividir de forma interativa, linha a linha, ou consultar o evolution log e dividir o trabalho na ordem em que ele foi realmente feito.

Transformar um branch de trabalho em uma cadeia de branches dependentes para um stacked PR dá muito trabalho no Git. No Jujutsu, basta ir colocando bookmarks, um depois do outro, em uma única linha do histórico. A documentação oficial do GitHub inclusive mostra, passo a passo, como montar a cadeia de branches de um stacked PR com o Jujutsu⁴. É bom ver essa afinidade reconhecida oficialmente.

O que é fácil para pessoas também é fácil para a IA

O Git foi projetado colocando as funcionalidades à frente de quem usa. O Jujutsu é um sistema de controle de versões criado para resolver os pontos fracos do Git⁵ e para manter a carga cognitiva das pessoas o mais baixa possível. E o que é fácil para a mente humana acaba sendo fácil para a IA também. Você nunca precisa se preocupar se uma edição já entrou no histórico, porque o estado do diretório de trabalho é o ponto atual do histórico. Um change mantém o mesmo ID não importa quantas vezes seja revisado, então ele nunca se perde durante longas rodadas de tentativa e erro. O operation log registra cada operação em ordem, então é fácil ver qual passo deu errado e restaurar a partir dali. E quando surge um conflito no meio de uma tarefa, o próprio estado em conflito é salvo no histórico, então você pode ir com calma e tentar resolvê-lo quantas vezes precisar. Cada uma dessas características é uma grande vantagem quando é a IA que está no comando.

O Jujutsu não está tão integrado às ferramentas dos agentes de IA quanto o Git. Mas é muito mais fácil para esses agentes entenderem como ele funciona, o que tende a tornar o trabalho deles mais estável e seguro. Mesmo que você entregue à IA o controle de versões junto com a programação, escolher o Jujutsu para essa tarefa faz todo o sentido.

Essa é a minha opinião, e também o argumento que desenvolvo no “Capítulo 1: Que tipo de ferramenta é o Jujutsu?” do meu livro, Juju-chu! — Comece seu fluxo de trabalho Jujutsu × IA com jj new. O capítulo desenvolve esse argumento ao explorar cada funcionalidade. O “Capítulo 3: Fluxo de trabalho Jujutsu × IA na prática” é um passo a passo prático de como realmente entregar a operação do Jujutsu ao Claude Code e ao Codex.

Juju-chu! — Comece seu fluxo de trabalho Jujutsu × IA com jj new

Um guia prático para adotar Jujutsu (jj) com Claude Code e Codex: snapshots automáticos, operações que podem ser desfeitas e reescrita segura do histórico.

juju-chu.com

Se este post despertou sua curiosidade pelo Jujutsu, dê uma olhada.

Footnotes

Para ser exata, sempre que qualquer comando jj é executado, o Jujutsu compara a cópia de trabalho com o estado mais recente do histórico. Se houver diferenças, ele tira um snapshot e o change ganha uma nova revisão. Se você usa uma interface gráfica do Jujutsu, ela normalmente tira um snapshot automaticamente sempre que você consulta o histórico nela. ↩
Um detalhe: um change sem descrição não pode ser enviado ao remoto com push. ↩
Veja Faça seu agente de programação usar Jujutsu em vez de Git. ↩
Usar outras ferramentas com solicitações de pull empilhadas - Documentos do GitHub ↩
Solving Git’s Pain Points with Jujutsu (with Martin von Zweigbergk) - YouTube ↩

Why I Still Choose Jujutsu When AI Can Handle Git

Yuka Ooka — Tue, 06 Oct 2026 12:00:00 +0000

“If an AI agent handles Git for you, why bother learning another version control system like Jujutsu?”

That was the most common pushback on my last post, 15 Years of Git, Then Jujutsu: Why I Can’t Go Back. It’s a fair question and an interesting one, so this post is my answer.

I agree that day-to-day version control is a job for an AI agent. That’s exactly how I work. The difference is that the commands my agents run are Jujutsu commands, not Git commands. Having done it both ways, I’m convinced that even when AI does the driving, Jujutsu makes for a much better developer experience, and that the time you spend learning it pays for itself quickly.

Before I make my case, there’s an obvious question to get out of the way: can AI actually handle Jujutsu? I checked with Opus, GPT, Gemini and others. The latest models already know Jujutsu’s core concepts and main commands out of the box, and they can handle everyday operations without loading any extra skills. That said, Jujutsu doesn’t get the first-class support Git does, so you need some configuration to stop the agent from drifting back to Git and to teach it a workflow that suits Jujutsu. Here’s the setup I use.

Git’s Commit Ceremony vs. Jujutsu’s Frictionless Changes

In Git, the basic unit of history is the commit. The standard workflow goes like this: you edit files in the working tree, pick the ones you want and add them to the index, then write a message and create a commit. Only then does anything land in history. A commit is meant to be a finished product, something you craft with care, which is why Git gives you the index as a staging area. Getting from an edited file to recorded history takes a long, rigid sequence of steps. It’s almost a ritual.

So even when you hand Git over to an AI, you still end every task by asking it to “commit this.” Ask for any history operation mid-task and you get the familiar back-and-forth: “You have uncommitted changes. Should I stash them, or commit first?” Each round may only take half a minute or so, but it happens constantly, and it adds up. There’s a cognitive cost too, paid by both you and the AI whether you notice it or not.

In Jujutsu, the basic unit of history is the change. When you initialize a repository, you start out in an empty change. Every edit you make there is saved as a new revision of that change as you go¹. You can add a description, Jujutsu’s equivalent of a commit message, whenever you like. A change never has a moment where it’s officially “done”². When you finish the work, you simply move on.

That means when an AI handles Jujutsu for you, all it takes is one standing instruction to start each task in a new change with a description³. After that you just say “build feature X,” and your history gets split into sensible units that follow the flow of the work. No more “commit this” at the end of every task, and no more being asked to tidy up your working copy before a history operation.

Jujutsu is compatible with Git, but there’s no index between your working directory and your local repository. On top of that, the state of your working directory is the current point in history (Jujutsu calls this “working copy as a commit”). In Git, humans and AI alike have to track three states for every change to a file. In Jujutsu, there’s normally just one. Only after switching did I realize how much extra mental effort I’d been spending to fit Git’s way of doing things, and how stressful all that bookkeeping had been.

Some of you will say this doesn’t bother you at all. Fair enough. Plenty of people genuinely don’t mind putting on a suit and getting to the office by 8:30 every morning. But imagine moving from that to a job with no dress code, flexible hours and remote work up to three days a week, and finding it so comfortable you could never go back. That’s what the switch felt like.

Jujutsu Makes AI Mistakes Easy to Undo

Humans make mistakes, and so does AI. I still see the occasional report of an AI agent deleting files someone was working on, with no way to get them back. Ask an agent to resolve a conflict and it’s not unusual to get a result that passes the tests but is semantically broken. And since you instruct agents in natural language, a prompt doesn’t always get your intent across, so you’ll often be unhappy with what comes back.

When the AI is running Git commands as part of its work, recovering from a bad result gets dramatically harder. Git has no way to roll the entire repository back to how it was before a given operation. As I mentioned, Git keeps state in several places: the working tree, the index, the stash and commits, and each one is protected in its own way, if at all. Rebase, amend and squash don’t modify existing commits. They create new ones and repoint the branch, so the originals are no longer referenced by any branch. They’re still in the reflog, but finding the right entry after the fact, buried among everything else, is a real chore.

To make up for Git not saving uncommitted changes, Claude Code offers a /rewind command that rolls the code back to an earlier point along with the conversation. But it doesn’t mix well with an agent that runs Git commands. Your files go back, but Git’s state doesn’t, so git status suddenly shows a pile of changes you never intended, and you’re back to cleaning up history. Anything changed by shell commands, by you, or by other agents running in parallel doesn’t get rolled back at all.

If you catch a mistake right away, you’re in decent shape. More often, though, it surfaces later, when you run the tests after more work or when you review things days afterward. By then it’s much harder to untangle. More operations have piled up on top of the bad one, and even if you go all in on the reflog, there’s no guarantee that a long series of delicate steps will actually fix things. Worse, Git gives you no way to undo a recovery attempt itself. An AI trying fix after fix to dig itself out can easily make things worse.

Jujutsu takes care of almost all of this. As a rule, the result of any jj command can be rolled back with jj undo, and the undo itself can be reversed with jj redo. That’s possible because Jujutsu keeps a record of every operation that changes the repository, the operation log , separate from the regular log. Each entry in the operation log is tied to a snapshot of the repository as it stood when that operation finished. You can restore the files to that state, or reverse just the effect of that one operation while keeping everything that came after it.

Every jj command an AI runs during a long session of trial and error ends up in the operation log too. When something goes wrong, you can look over everything the AI did, pin down the cause, and go back to the state just before things went sideways.

And unlike a Git commit hash, which changes every time you edit the commit, a Jujutsu change-ID stays the same no matter how many times the change is revised. You can browse a change’s revision history in the evolution log , and with a little digging, you can trace it back and restore an earlier version’s contents. Narrow it down by timestamp or diff, and you can even recover from a botched conflict resolution from several days ago and redo it.

Every edit gets saved to history as you go. The operation log and the evolution log let you find where things went wrong and go back to that point. And if the recovery itself goes wrong, jj undo and jj redo let you try again right away. That’s a level of safety Git simply doesn’t offer, and it’s exactly why I can hand version control to an AI more casually, and more boldly, with Jujutsu than I ever could with Git.

Why Clean History Matters More in the Age of AI Coding

Another comment that stood out on my last post was “I don’t care about keeping a clean history, so I don’t see the point of Jujutsu.” The reasoning seems to be that even if the history is a mess, you can just ask AI to dig out whatever you need. But is that really true? I’d argue the opposite: precisely because AI means we write and read less code ourselves, a clean history matters more than ever.

Coding agents have improved so much that plenty of developers now barely write code themselves, and don’t read every line the AI generates either. Even so, they still guard the quality of what ships, by having an agent running a different model review the work, or by checking the critical parts, like data structure changes, themselves. If you can trace what changed, why, and what it depends on straight from the history, all of that gets faster and less error-prone. Precisely because nobody is reviewing every line, your commit history needs to work as a table of contents for the code , so you can find the parts that matter. A string of giant commits with no clear intent forces the AI to pull irrelevant context in every time, which burns tokens and can hurt the quality of its work.

At the start of each session, an agent will usually look at the most recent meaningful diffs before it looks at the working directory as a whole. Cram “a bug fix + a dependency update + some unrelated content + an unrelated refactor” into a single commit, and the agent gets confused. Line up commits of sensible size with clear intent, in an order that reflects cause and effect, and even a short prompt gives the agent the context it needs for the next task.

And even if you barely read AI-generated code during development, an incident will force you to read it carefully. The first question in a production outage is “when and where did the bad code get in?” When every minute counts, a history of semantically coherent commits helps you pinpoint the problem fast.

AI coding has also created a new problem as productivity has shot up: PRs get huge → they get hard to review → unmerged PRs pile up waiting for review. Now even teams of just a few people are stuck in that loop. Big tech companies like Google and Meta have been dealing with this problem for more than a decade, and their answer has been to “split PRs into small units that depend on each other.” Say you’d normally submit a whole feature as one PR. Instead, you split it into “1. model layer changes,” “2. scheduled job changes,” “3. server API changes” and “4. web frontend changes,” and stack them 1 → 2 → 3 → 4. Each can be reviewed, approved and merged on its own, but a PR can only be merged once the PRs below it in the stack (for 3, that’s 1 and 2) have merged. These companies built that into their tooling and ran it as part of everyday development.

Small PRs with a clear, logical role are easier on reviewers, and it’s easier to spot the ones that are yours to review. Changes to a PR branch lower in the stack propagate automatically to the branches above it, rebased by the tooling. And thanks to the dependencies, you can safely start on the next piece of work while the first PR is still waiting for review. This is what’s commonly called stacked diffs or stacked PRs. Graphite, GitButler, GitLab and others have been rolling out support for years now. And in July 2026, GitHub finally launched stacked PRs in public preview. With the biggest player on board, the trend looks set to pick up speed.

Between monorepos becoming the norm and the impact of AI agents, demand for stacked PRs is growing not just at big companies but at small and mid-sized ones too. Once stacked PRs are part of how a team works, getting the units of history and their order right becomes part of every developer’s job. PRs you could once stuff with anything now have to be split by logical role, with dependencies between them. And Jujutsu makes that easy and safe.

Take splitting a giant commit into meaningful units. It’s a hard task, even for AI. In Git, you’d probably git reset HEAD^ to dump the whole commit back into the working tree, then repeat the index-then-commit cycle piece by piece. Slip up along the way, and recovery means figuring out exactly how far you got with the split and which edits are left where—a headache in itself. If you’re splitting an older commit, you’re in for the thrill of repeated rebases with a detached HEAD. In Jujutsu, you pass the files to jj split -m <description> and you’re done. Get it wrong, and you undo and try again. When an AI does these, the split works at the file level, but a human running Jujutsu can use jj split -i to split interactively line by line, or consult the evolution log and split the work in the order it was actually done.

Turning a working branch into a chain of dependent branches for a stacked PR is a real hassle in Git. In Jujutsu, you just put bookmarks, one after another, on a single line of history. GitHub’s own docs even walk through building a stacked-PR branch chain with Jujutsu⁴. It’s nice to see the fit recognized officially.

What’s Easy on Humans Is Easy on AI Too

Git was designed with features first. Jujutsu is a version control system built to fix Git’s pain points⁵ and to keep the cognitive load on humans as low as possible. What’s easy on human minds turns out to be easy on AI as well. You never have to worry whether an edit has made it into history, because the state of the working directory is the current point in history. A change keeps the same ID however many times it’s revised, so it never gets lost during long rounds of trial and error. The operation log records every operation in order, so it’s easy to see which step went wrong and restore from there. And when a conflict comes up mid-task, the conflicted state itself is saved to history, so you can take your time and try resolving it as many times as you need. Every one of these is a big advantage when AI is the one at the controls.

Jujutsu doesn’t get the same first-class support from AI agents that Git does. But it’s far easier for them to reason about, and that tends to make their work more stable and safer. Even if you’re handing version control to AI along with the coding, choosing Jujutsu for the job just makes sense.

That’s my take, and it’s also the argument I develop in “Chapter 1: What Kind of Tool Is Jujutsu?” of my book, Juju-chu! — Starting Your Jujutsu × AI Workflow with jj new. The chapter walks through the same argument feature by feature. “Chapter 3: Jujutsu × AI Workflow in Practice” is a hands-on walkthrough of actually handing Jujutsu over to Claude Code and Codex.

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

If this post got you curious about Jujutsu, take a look.

Footnotes

To be precise, whenever any jj command runs, Jujutsu checks the working copy against the latest state in history. If they differ, it takes a snapshot and the change gets a new revision. If you use a Jujutsu UI tool, it usually takes a snapshot automatically whenever you view the history there. ↩
One catch: a change with no description can’t be pushed to the remote. ↩
See Make Your Coding Agent Use Jujutsu Instead of Git. ↩
Use other tools with stacked pull requests - GitHub Docs ↩
Solving Git’s Pain Points with Jujutsu (with Martin von Zweigbergk) - YouTube ↩

Por qué sigo eligiendo Jujutsu aunque la IA pueda encargarse de Git

Yuka Ooka — Tue, 06 Oct 2026 12:00:00 +0000

«Si un agente de IA ya se encarga de Git, ¿para qué aprender otro sistema de control de versiones como Jujutsu?»

Esa fue la objeción más repetida a mi último artículo, 15 años de Git y luego Jujutsu: por qué ya no puedo volver. Es una pregunta razonable y, además, interesante, así que este artículo es mi respuesta.

Estoy de acuerdo en que el control de versiones del día a día es trabajo para un agente de IA. Así es exactamente como trabajo yo. La diferencia es que los comandos que ejecutan mis agentes son de Jujutsu, no de Git. Después de probar las dos cosas, estoy convencida de que, incluso cuando la IA va al volante, Jujutsu ofrece una experiencia de desarrollo mucho mejor, y de que el tiempo que inviertes en aprenderlo se recupera enseguida.

Antes de exponer mis argumentos, conviene despejar una duda evidente: ¿de verdad la IA sabe manejar Jujutsu? Lo comprobé con Opus, GPT, Gemini y otros. Los modelos más recientes ya conocen los conceptos básicos y los comandos principales de Jujutsu, y pueden encargarse de las operaciones cotidianas sin cargar ningún skill adicional. Eso sí, Jujutsu no está tan integrado en las herramientas de los agentes como Git, así que hace falta algo de configuración para evitar que el agente vuelva a Git sin avisar y para enseñarle un flujo de trabajo adecuado para Jujutsu. Esta es la configuración que uso yo.

La ceremonia del commit en Git frente a los changes sin fricción de Jujutsu

En Git, la unidad básica del historial es el commit. El flujo estándar es este: editas archivos en el working tree, eliges los que quieres y los añades al índice, y después escribes un mensaje y creas un commit. Solo entonces queda algo registrado en el historial. Un commit está pensado para ser un producto terminado, algo que se elabora con cuidado, y por eso Git te ofrece el índice como área de staging. Editar un archivo y lograr que esos cambios queden registrados en el historial exige una secuencia de pasos larga y rígida. Es casi un ritual.

Así que, aunque le cedas Git a una IA, sigues terminando cada tarea pidiéndole «haz commit de esto». Pide cualquier operación sobre el historial a mitad de una tarea y llega el intercambio de siempre: «Tienes cambios sin commit. ¿Los guardo en el stash o hago commit primero?». Cada ronda quizá solo lleve medio minuto, pero ocurre constantemente y todo suma. También hay un costo cognitivo, que pagan tanto tú como la IA, lo notes o no.

En Jujutsu, la unidad básica del historial es el change. Cuando inicializas un repositorio, empiezas en un change vacío. Cada edición que haces ahí se guarda sobre la marcha como una nueva revisión de ese change¹. Puedes añadirle una descripción, el equivalente en Jujutsu a un mensaje de commit, cuando quieras. Un change nunca tiene un momento en que quede oficialmente «terminado»². Cuando acabas el trabajo, simplemente pasas a otra cosa.

Eso significa que, cuando una IA maneja Jujutsu por ti, basta con una instrucción permanente: empezar cada tarea en un change nuevo con su descripción³. A partir de ahí solo tienes que decir «crea la funcionalidad X», y tu historial queda dividido en unidades razonables que siguen el hilo del trabajo. Se acabó el «haz commit de esto» al final de cada tarea, y se acabó que te pidan ordenar la copia de trabajo antes de una operación sobre el historial.

Jujutsu es compatible con Git, pero no hay ningún índice entre tu directorio de trabajo y tu repositorio local. Es más, el estado de tu directorio de trabajo es el punto actual del historial (Jujutsu lo llama «working copy as a commit», la copia de trabajo como commit). En Git, tanto las personas como la IA tienen que seguir la pista de tres estados por cada cambio en un archivo. En Jujutsu, normalmente hay solo uno. Solo después de pasarme a Jujutsu me di cuenta de cuánto esfuerzo mental extra gastaba en ajustarme a la forma de hacer las cosas de Git, y de lo estresante que era todo ese llevar la cuenta.

Habrá quien diga que esto no le molesta en absoluto. Me parece bien. Hay mucha gente a la que de verdad no le importa ponerse traje y estar en la oficina a las 8:30 cada mañana. Pero imagina pasar de eso a un trabajo sin código de vestimenta, con horario flexible y trabajo remoto hasta tres días por semana, y encontrarlo tan cómodo que ya no podrías volver atrás. Eso es lo que sentí con el cambio.

Jujutsu hace que los errores de la IA sean fáciles de deshacer

Las personas cometemos errores, y la IA también. Todavía veo de vez en cuando casos de agentes de IA que borran archivos con los que alguien estaba trabajando, sin forma de recuperarlos. Pídele a un agente que resuelva un conflicto y no es raro recibir un resultado que pasa los tests pero está roto a nivel semántico. Y como a los agentes se les dan instrucciones en lenguaje natural, un prompt no siempre transmite bien tu intención, así que a menudo no te convencerá lo que recibes.

Cuando la IA ejecuta comandos de Git como parte de su trabajo, recuperarse de un mal resultado se vuelve muchísimo más difícil. Git no tiene forma de devolver todo el repositorio al estado en que estaba antes de una operación concreta. Como comenté, Git guarda el estado en varios sitios: el working tree, el índice, el stash y los commits, y cada uno está protegido a su manera, si es que lo está. Rebase, amend y squash no modifican los commits existentes. Crean otros nuevos y mueven la rama hacia ellos, de modo que los commits originales ya no están referenciados por ninguna rama. Siguen en el reflog, pero encontrar la entrada correcta después, enterrada entre todo lo demás, es un verdadero dolor de cabeza.

Para compensar que Git no guarda los cambios sin commit, Claude Code ofrece el comando /rewind, que devuelve el código a un punto anterior junto con la conversación. Pero no se lleva bien con un agente que ejecuta comandos de Git. Tus archivos vuelven atrás, pero el estado de Git no, así que de repente git status muestra un montón de cambios que nunca quisiste, y otra vez te toca poner orden en el historial. Y lo que se haya cambiado con comandos de shell, a mano o mediante otros agentes que se ejecutan en paralelo no se revierte en absoluto.

Si detectas un error en el momento, todavía vas bien. Pero lo más habitual es que salga a la luz más tarde, cuando ejecutas los tests después de seguir trabajando o cuando revisas las cosas días después. Para entonces es mucho más difícil desenredarlo. Se han acumulado más operaciones encima de la errónea y, aunque te emplees a fondo con el reflog, nada garantiza que una larga serie de pasos delicados vaya a arreglarlo. Peor aún, Git no te da ninguna forma de deshacer el propio intento de recuperación. Una IA que prueba un arreglo tras otro para salir del agujero puede empeorar las cosas con facilidad.

Jujutsu resuelve casi todo esto. Por regla general, el resultado de cualquier comando jj se puede revertir con jj undo, y el propio undo se puede deshacer con jj redo. Esto es posible porque Jujutsu lleva, aparte del log normal, un registro de cada operación que modifica el repositorio: el operation log. Cada entrada del operation log está ligada a una instantánea del repositorio tal como quedó al terminar esa operación. Puedes restaurar los archivos a ese estado, o revertir solo el efecto de esa operación conservando todo lo que vino después.

Cada comando jj que ejecuta una IA durante una larga sesión de ensayo y error también queda en el operation log. Cuando algo sale mal, puedes repasar todo lo que hizo la IA, localizar la causa y volver al estado justo anterior a que las cosas se torcieran.

Además, a diferencia del hash de un commit de Git, que cambia cada vez que editas el commit, el change ID de Jujutsu se mantiene igual por muchas veces que se revise el change. Puedes consultar el historial de revisiones de un change en el evolution log y, con un poco de trabajo, seguirle la pista hacia atrás y restaurar el contenido de una versión anterior. Si lo acotas por fecha y hora o por diff, puedes incluso recuperarte de una resolución de conflictos fallida de hace varios días y volver a hacerla.

Cada edición se guarda en el historial sobre la marcha. El operation log y el evolution log te permiten encontrar dónde se torcieron las cosas y volver a ese punto. Y si la propia recuperación sale mal, jj undo y jj redo te dejan intentarlo de nuevo al momento. Es un nivel de seguridad que Git sencillamente no ofrece. Por eso, con Jujutsu me siento mucho más cómoda delegando el control de versiones a una IA y dejando que actúe con más audacia.

Por qué un historial limpio importa más en la era de la programación con IA

Otro comentario que destacó en mi último artículo fue «no me importa mantener el historial limpio, así que no le veo sentido a Jujutsu». El razonamiento parece ser que, aunque el historial sea un desastre, basta con pedirle a la IA que encuentre lo que necesites. Pero ¿es realmente así? Yo diría que es al revés: precisamente porque con la IA escribimos y leemos menos código, un historial limpio importa más que nunca.

Los agentes de programación han mejorado tanto que muchos desarrolladores ya apenas escriben código y tampoco leen cada línea que genera la IA. Aun así, siguen velando por la calidad de lo que se publica, ya sea haciendo que un agente con otro modelo revise el trabajo o revisando por su cuenta las partes críticas, como los cambios en las estructuras de datos. Si puedes rastrear directamente en el historial qué cambió, por qué y de qué depende, todo eso se hace más rápido y con menos errores. Precisamente porque nadie revisa cada línea, tu historial de commits tiene que funcionar como el índice del código , para que puedas encontrar las partes que importan. Una sucesión de commits gigantes sin una intención clara obliga a la IA a cargar contexto irrelevante cada vez, lo que consume tokens y puede perjudicar la calidad de su trabajo.

Al empezar cada sesión, lo normal es que un agente mire los diffs significativos más recientes antes que el directorio de trabajo en su conjunto. Mete «una corrección de bug + una actualización de dependencias + contenido sin relación + una refactorización que no viene a cuento» en un solo commit, y el agente se confunde. Ordena commits de tamaño razonable y con una intención clara, en una secuencia que refleje la relación de causa y efecto, y hasta un prompt corto le dará al agente el contexto que necesita para la siguiente tarea.

Y aunque durante el desarrollo apenas leas el código que genera la IA, un incidente te obligará a leerlo con atención. La primera pregunta ante una caída en producción es «¿cuándo y dónde entró el código problemático?». Cuando cada minuto cuenta, un historial de commits semánticamente coherentes te ayuda a localizar el problema rápido.

La programación con IA también ha creado un problema nuevo al disparar la productividad: los PR se vuelven enormes → cuesta revisarlos → los PR sin fusionar se acumulan esperando revisión. Ahora incluso equipos de unas pocas personas caen en ese círculo. Grandes tecnológicas como Google y Meta llevan más de una década lidiando con este problema, y su respuesta ha sido «dividir los PR en unidades pequeñas que dependen unas de otras». Supón que normalmente enviarías una funcionalidad entera como un solo PR. En su lugar, la divides en «1. cambios en la capa de modelo», «2. cambios en las tareas programadas», «3. cambios en la API del servidor» y «4. cambios en el frontend web», y los apilas 1 → 2 → 3 → 4. Cada uno se puede revisar, aprobar y fusionar por separado, pero un PR solo se puede fusionar cuando ya se han fusionado los que tiene debajo en la pila (para el 3, el 1 y el 2). Estas empresas lo integraron en sus herramientas y lo usaban en el desarrollo del día a día.

Los PR pequeños y con un papel lógico claro les ponen las cosas más fáciles a los revisores, y es más fácil identificar los que te toca revisar. Los cambios en la rama de un PR situado más abajo en la pila se propagan automáticamente a las ramas de encima, a las que las herramientas aplican el rebase. Y gracias a las dependencias, puedes empezar con seguridad la siguiente parte del trabajo mientras el primer PR sigue esperando revisión. Esto es lo que se suele llamar stacked diffs o stacked PRs. Graphite, GitButler, GitLab y otros llevan años incorporándolo. Y en julio de 2026, GitHub por fin lanzó los stacked PRs en vista previa pública. Con el actor principal ya a bordo, todo apunta a que la tendencia va a acelerarse.

Con la generalización de los monorepos y el impacto de los agentes de IA, la demanda de stacked PRs está creciendo no solo en las grandes empresas, sino también en las pequeñas y medianas. Cuando los stacked PRs forman parte de la forma de trabajar de un equipo, organizar bien las unidades del historial y su orden pasa a ser parte del trabajo de cada desarrollador. Los PR en los que antes cabía cualquier cosa, ahora hay que dividirlos según su papel lógico, con dependencias entre ellos. Y Jujutsu hace que eso sea fácil y seguro.

Pensemos en dividir un commit gigante en unidades con sentido. Es una tarea difícil, incluso para la IA. En Git, probablemente harías git reset HEAD^ para devolver todo el commit al working tree y luego repetirías el ciclo de añadir al índice y hacer commit, parte por parte. Si te equivocas por el camino, recuperarte implica averiguar exactamente hasta dónde llegaste con la división y qué ediciones quedaron dónde, lo que ya es un dolor de cabeza en sí mismo. Y si el commit que quieres dividir es antiguo, te espera la emoción de encadenar rebases con un HEAD desacoplado (detached HEAD). En Jujutsu, le pasas los archivos a jj split -m <description> y listo. Si te equivocas, deshaces y vuelves a intentarlo. Cuando lo hace una IA, la división es a nivel de archivo, pero una persona que maneje Jujutsu puede usar jj split -i para dividir de forma interactiva línea a línea, o consultar el evolution log y dividir el trabajo en el orden en que realmente se hizo.

Convertir una rama de trabajo en una cadena de ramas dependientes para un stacked PR es bastante complicado en Git. En Jujutsu, basta con ir poniendo bookmarks, uno tras otro, sobre una sola línea del historial. La documentación oficial de GitHub incluso explica paso a paso cómo crear la cadena de ramas de un stacked PR con Jujutsu⁴. Es genial ver esa compatibilidad reconocida oficialmente.

Lo que es fácil para las personas también lo es para la IA

Git se diseñó poniendo las funcionalidades por delante de quien las usa. Jujutsu es un sistema de control de versiones creado para resolver los puntos débiles de Git⁵ y para reducir al mínimo la carga cognitiva de las personas. Y lo que le resulta fácil a la mente humana también le resulta fácil a la IA. Nunca tienes que preocuparte de si una edición ha llegado al historial, porque el estado del directorio de trabajo es el punto actual del historial. Un change conserva el mismo ID por muchas veces que se revise, así que nunca se pierde durante largas rondas de ensayo y error. El operation log registra cada operación en orden, así que es fácil ver qué paso salió mal y restaurar desde ahí. Y cuando surge un conflicto a mitad de una tarea, el propio estado en conflicto se guarda en el historial, así que puedes tomarte tu tiempo e intentar resolverlo tantas veces como haga falta. Cada una de estas características es una gran ventaja cuando es la IA quien está a los mandos.

Jujutsu no está tan integrado en las herramientas de los agentes de IA como Git. Pero les resulta mucho más fácil de entender, y eso tiende a hacer su trabajo más estable y seguro. Aunque le cedas a la IA el control de versiones junto con la programación, elegir Jujutsu para esa tarea tiene todo el sentido.

Esa es mi opinión, y también el argumento que desarrollo en el «Capítulo 1: ¿Qué clase de herramienta es Jujutsu?» de mi libro, Juju-chu! —Comienza tu flujo de trabajo Jujutsu × IA con jj new. Ese capítulo recorre el mismo argumento funcionalidad por funcionalidad. El «Capítulo 3: El flujo Jujutsu × IA en la práctica» es una guía práctica para cederles de verdad el manejo de Jujutsu a Claude Code y Codex.

Juju-chu! —Comienza tu flujo de trabajo Jujutsu × IA con jj new

Una guía práctica para adoptar Jujutsu (jj) junto a Claude Code y Codex: snapshots automáticos, operaciones que siempre se pueden deshacer y una reescritura del historial que es segura.

juju-chu.com

Si este artículo despertó tu curiosidad por Jujutsu, échale un vistazo.

Footnotes

Para ser exactos, cada vez que se ejecuta cualquier comando jj, Jujutsu compara la copia de trabajo con el último estado del historial. Si hay diferencias, toma una instantánea y el change recibe una nueva revisión. Si usas una interfaz gráfica de Jujutsu, normalmente toma una instantánea automáticamente cada vez que consultas el historial en ella. ↩
Eso sí: un change sin descripción no se puede enviar al remoto con push. ↩
Consulta Haz que tu agente de programación use Jujutsu en vez de Git. ↩
Uso de otras herramientas con solicitudes de incorporación de cambios apiladas - Documentación de GitHub ↩
Solving Git’s Pain Points with Jujutsu (with Martin von Zweigbergk) - YouTube ↩

15 Years of Git, Then Jujutsu: Why I Can’t Go Back

Yuka Ooka — Tue, 29 Sep 2026 00:29:00 +0000

2026: The First VCS I Actually Chose

Looking back, I never really chose a version control system (VCS). I used whatever the company I worked for had picked. Most of my earlier workplaces ran Subversion on an in-house server. Then in 2011 I joined a company that had adopted GitHub, which meant every engineer was expected to use Git. That’s when I started using Git and GitHub for real.

Coming from Subversion, Git felt unintuitive and hard to use. GitHub also brought a new expectation: clean up your history so it’s easy to review. The commands for doing that were inconsistent and hard to remember, and each one carried the kind of pressure where you can’t afford to slip.

Over time I went numb to it and accepted that this was just how things were. I still couldn’t remember the commands, though. Anything slightly complicated meant a trip to Google, and I steered clear of anything that might cause a conflict. Five years went by that way, then ten. Just as it looked like fifteen would pass the same way, everything changed. AI coding agents like Claude Code arrived, and almost before I knew it, AI was writing more code than humans were. A few years earlier I wouldn’t have believed it.

Give an AI instructions and it writes the code in no time. With everything moving that much faster, Git’s friction-heavy add-then-commit ritual became a real bottleneck. If it worked, I’d commit it for the time being, even if I didn’t yet understand it as thoroughly as code I’d written myself. Then, inevitably, I’d want to change things later. I’d lose important changes somewhere in rebase hell, or give up and pile quick-fix commits on top until the history was a mess. This became an everyday thing.

That’s when I found Jujutsu. In Japan, a wave of introductory articles made the rounds around January 2026, and ordinary developers started to notice it. After reading a few, I figured it would pair well with AI coding and tried it on a project I was working on. Its design philosophy and commands are so different from Git’s that at first I struggled to use it. What kept me from giving up was how much simpler things felt without a staging area, and the comfort of knowing any operation could be undone. After about a month, I could use it reasonably well.

Since then I’ve managed every repository with Jujutsu, and I do all my writing in it too, from blog posts and docs to book manuscripts (this post included, of course). Now that I think about it, moving from Git to Jujutsu was the first time I’d ever chosen a VCS myself. And somewhere along the way, I realized I couldn’t go back to Git. Here are the reasons, as I see them, that I have no desire to go back.

Reason 1: I Never Have to Wonder Whether My Work Is Saved

Git uses a three-state model: working tree → index → local repository. To record a change in history, you first stage it with git add, then run git commit. In Jujutsu, the state of your working copy is itself a commit. From Jujutsu’s point of view, there’s no gap between your working directory and the current commit. Which comes with a few practical upsides:

You never have to decide when to save to history
You don’t need anything like git stash when switching tasks
You’re very unlikely to lose work in progress

Keeping track of which files are unstaged or haven’t made it into a commit yet is cognitive overhead that has nothing to do with the actual development work. So is pushing and popping stashes when something unexpected interrupts you. Jujutsu brings those costs close to zero.

For AI coding, with the right configuration, all you have to do is ask an agent to “build feature X.” The work lands in a single commit as it happens, and the agent finishes it off with a message like “feat: X”. In the normal flow, you don’t do any history bookkeeping at all.

You also almost never hit the accident where git reset, git clean, or a shell command deletes files you can’t get back. I’ve had an AI agent delete files I couldn’t recover, and even now, when models are supposedly far better than they used to be, I still see reports of it now and then. Jujutsu commits the working copy as you go¹, so in most cases anything deleted by mistake can be recovered from history.

If I were forced back to Git, I’d have to start thinking about saving again, and I’d always be one bad command away from losing work in progress. Just picturing it wears me out. Jujutsu lowers the cognitive load of version control and gives me peace of mind.

Reason 2: Experimenting Is Far Cheaper

Now that an AI agent can build whatever I ask for in moments, I do a lot more trial and error: build something, keep it if it’s good, throw it away and try again if it isn’t. Doing that in Git gets awkward fast. If you experiment in the working tree without committing, you’re stuck when you throw something away and then decide you wanted it after all. If you want it saved, you need branches, and creating, switching, merging and deleting them is enough of a chore that the whole thing suddenly feels heavy.

So how does Jujutsu handle it? The basic unit of history in Jujutsu, roughly equivalent to a Git commit, is the change. When Jujutsu detects edits in the working copy, it updates the current change automatically and keeps the earlier versions too. You just experiment inside a change. Create a new one with jj new and try whatever you want. If you like the result, give it a description (roughly, a commit message). If you don’t, drop it with jj abandon. If you later want it back, jj operation revert <operation ID> undoes the deletion², and if you only just deleted it, a single jj undo brings it back.

Jujutsu also lets you branch off history at any point without naming anything. Just pass the parent change’s ID to jj new. To compare different approaches to the same task, create several of these sibling changes and move between them with jj edit <change ID>. Give the one you want to keep a description, and jj abandon the rest. That’s it.

Because the change, Jujutsu’s basic unit of history, doubles as a sandbox, experimenting is just part of normal workflow. No merge needed. And since you can’t tell whether an experiment will pan out when you start it, you don’t have to name it up front either.

If I were forced back to Git, I’d definitely be more reluctant to experiment. I can already see myself skipping the branch because it’s a hassle, experimenting in the working tree, throwing something away, wanting it back, and kicking myself.

Reason 3: Rewriting History Is Simple and Intuitive

When I wrote the code myself, I knew it inside out, so my commits were solid and I rarely had to go back to them. But hardly anyone reads every line an AI generates and understands it as well as their own code before committing. So I find myself wanting to change supposedly finished commits far more often than I used to.

Say you want to fold a change to src/styles/global.css into the commit three back. What does that look like in Git, and in Jujutsu? There are two ways to go about it: edit the target commit directly, or make the change on top and squash it into the target commit. Here I’ll compare the first.

Let’s start with Git. You can’t do this with uncommitted changes lying around, so if you have any, you first need to stash them with git stash -u. Then:

git rebase -i HEAD~4

In the editor that opens, change pick to edit on the target commit’s line and save.

- pick bbbbbbb Commit message for B
+ edit bbbbbbb Commit message for B
  pick ccccccc Commit message for C
  pick ddddddd Commit message for D
  pick eeeeeee Commit message for E

Your working tree is now at commit B. Edit src/styles/global.css, then commit it.

git add src/styles/global.css
git commit --amend --no-edit

But you’re not done. The commits after it still need to be replayed on top of that edit. Run git rebase --continue and pray there’s no conflict. If there is, the rebase stops, and you fix the files, git add, and git rebase --continue again, as many times as it takes. If you lose track of what’s going on, git rebase --abort sends you back to square one. It wears you out.

Now the same thing in Jujutsu. jj edit @--- moves the working copy to the change three back. Edit src/styles/global.css. Jujutsu automatically rebases the descendant changes onto it, so if there are no conflicts, you’re done. Even if a conflict comes up, the automatic rebase finishes without stopping. Just jj edit your way to the conflicted change and fix it there, and the automatic rebase runs again.

Fewer steps is a nice bonus, but the bigger win is that it feels far more intuitive. Go to the point in history you care about and edit the files. Jujutsu handles the rebasing on its own, so you barely notice it’s happening. In Git, for some reason, rebase is the star of the show. You start with git rebase and you finish with git rebase. It’s counterintuitive, and the steps in between are fiddly enough that I never did manage to memorize them.

If I were forced back to Git, I’d probably avoid rewriting history whenever I could because of the hassle. Quick-fix commits would pile up, or unrelated changes would get stuffed into whatever commit was handy, and my history would get much harder to read.

Reason 4: I See History as a Graph, Not Just a Timeline

Let’s start by comparing the output of each tool’s log command. The first is git log, the second jj log. By default Jujutsu hides most immutable changes, so I passed -r :: to lift that limit.

Git’s log shows what happened on your current branch, in order, in a straight line like a timeline in a history textbook. Jujutsu’s log gives you a bird’s-eye view of the whole history, draws the branching with ASCII art, and packs in more information. You take in far more at a glance.

What happens when you move to a past point in history is different too. Run git checkout <commit ID> in Git, and git log no longer shows anything after that point. Run jj edit <change ID> in Jujutsu, and the log stays as it was. Only the @ marker, which stands for the working-copy commit, moves to that change’s node.

These differences in how the log looks and behaves say a lot about the two tools’ design philosophies. In Git, you’re generally expected to be on some named branch while you work, and you’re always being pushed to the tip of that one line of history. That may be why the default log doesn’t bother showing where you are in the overall history or what’s happening outside that timeline³.

Jujutsu has nothing that corresponds to Git’s named branches⁴. You can move freely to any editable node in the history, regardless of which line it sits on. That’s why a graph of the overall history is so useful.

A lot of what makes rewriting history easy in Jujutsu comes down to this dense, readable log. It’s like working in video editing software with a multi-track timeline in front of you. By comparison, editing history in Git feels like cutting analog film with scissors and gluing the pieces back together.

git log can draw an ASCII tree graph too if you pass --graph, though it’s not as readable as Jujutsu’s. But seeing the graph doesn’t let you edit across branches intuitively and safely the way Jujutsu does, so even if I went back to Git, I’d hardly ever use it.

Where Git Fits In Now

It’s been over six months since I switched to Jujutsu completely, but I haven’t actually stopped using Git. Jujutsu’s storage layer is pluggable, and it can use a Git repository as its backend. When you initialize a repository with Jujutsu, by default you get a colocated workspace, with .git/ and .jj/ sitting side by side in the project root. I’m still using a Git repository. I’ve just stopped using Git’s interface to it. The git command still works if you want it.

Because of that compatibility, nobody around you can tell you’re using Jujutsu unless you say so. On a team using GitHub or GitLab, it’s entirely possible someone has been quietly using Jujutsu all along. Day to day, about the only times I think about Git are when I set up a repository with jj git init or jj git clone, and after that when I sync with the remote using jj git fetch and jj git push.

I started using Git because of GitHub, and I switched to Jujutsu when I went all in on AI coding. Now there’s no going back. After years of being trained by Git, some of Jujutsu’s ways felt odd at first. But when you look at the history of version control, it often turns out Git was the odd one, and these days Jujutsu feels more natural to me in most situations.

Jujutsu is still niche, though, and it frustrates me that a tool this good isn’t better known. The catch is that it’s compatible with Git but built on a very different mental model. If you try it with a Git mindset, working from a Git-to-jj command comparison, you’ll barely notice the benefits. So I wrote a beginner-friendly Jujutsu guide designed so you won’t get stuck , one built around switching mental models.

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

It’s called Juju-chu! — Starting Your Jujutsu × AI Workflow with jj new, and with its light-novel-style cover it looks pretty playful, but the content is the real deal. It takes Jujutsu beginners step by step to the point where they can use it with confidence. If this post got you curious about Jujutsu, take a look. The page above has a sample you can read right in your browser.

Footnotes

To be precise, whenever any jj command runs, Jujutsu checks for differences between the working copy and the latest state in history, and commits them if there are any. AI agents told to use Jujutsu typically check their work with jj status or a similar command at natural breaks in a task, and that’s when the commit happens. ↩
Separately from the regular log, Jujutsu keeps an operation log that records every operation performed on the repository. Each entry has an operation ID, which you can use to reverse that operation or restore the files as they were right after it. ↩
This refers to the default behavior. With --all, you’ll see every branch in your local repository and the commits reachable from them. ↩
Jujutsu’s bookmarks are treated as branches when working with Git, but conceptually they’re a different thing. ↩

15 años de Git y luego Jujutsu: por qué ya no puedo volver

Yuka Ooka — Mon, 28 Sep 2026 00:37:00 +0000

2026: el primer VCS que elegí de verdad

Mirando hacia atrás, nunca llegué a elegir un sistema de control de versiones (VCS). Usaba el que hubiera escogido la empresa en la que trabajaba. En la mayoría de mis trabajos anteriores se usaba Subversion en un servidor interno. Luego, en 2011, entré en una empresa que había adoptado GitHub, así que a todos los ingenieros se nos pedía usar Git. Fue entonces cuando empecé a usar Git y GitHub en serio.

Viniendo de Subversion, Git me parecía poco intuitivo y difícil de usar. GitHub trajo además una nueva exigencia: dejar el historial limpio para que fuera fácil de revisar. Los comandos necesarios para ello eran incoherentes y difíciles de recordar, y cada uno venía con esa presión de saber que no te puedes permitir un error.

Con el tiempo se me adormeció esa sensación y acepté que las cosas eran así. Aun así, seguía sin recordar los comandos. Cualquier cosa un poco complicada implicaba buscar en Google, y evitaba todo lo que pudiera provocar un conflicto. Así pasaron cinco años, luego diez. Justo cuando parecía que los quince pasarían igual, todo cambió. Llegaron los agentes de programación con IA como Claude Code y, casi sin darme cuenta, la IA ya escribía más código que las personas. Unos años antes no me lo habría creído.

Dale instrucciones a una IA y escribirá el código en un abrir y cerrar de ojos. Con todo avanzando tan rápido, el tedioso ritual de add y commit de Git se convirtió en un verdadero cuello de botella. Si funcionaba, hacía commit de momento, aunque todavía no lo entendiera tan a fondo como el código que había escrito yo. Y luego, inevitablemente, quería cambiar cosas. Perdía cambios importantes en algún punto del infierno del rebase, o me rendía y apilaba commits de parche encima hasta dejar el historial hecho un desastre. Aquello se convirtió en el pan de cada día.

Fue entonces cuando descubrí Jujutsu. En Japón, hacia enero de 2026, circuló una oleada de artículos introductorios y la comunidad de desarrolladores en general empezó a prestarle atención. Después de leer unos cuantos, pensé que encajaría bien con la programación con IA y lo probé en un proyecto en el que estaba trabajando. Su filosofía de diseño y sus comandos son tan distintos de los de Git que al principio me costó mucho usarlo. Lo que evitó que tirara la toalla fue lo sencillo que resultaba todo sin área de staging, y la tranquilidad de saber que cualquier operación se podía deshacer. Al cabo de un mes, más o menos, ya lo manejaba razonablemente bien.

Desde entonces gestiono todos mis repositorios con Jujutsu, y también escribo todo con él, desde entradas de blog y documentación hasta manuscritos de libros (este artículo incluido, por supuesto). Pensándolo bien, pasar de Git a Jujutsu fue la primera vez que elegí un VCS por mi cuenta. Y en algún momento me di cuenta de que ya no podía volver a Git. Estas son, a mi juicio, las razones por las que no tengo ningunas ganas de volver.

Razón 1: nunca tengo que preguntarme si mi trabajo está guardado

Git usa un modelo de tres estados: working tree → índice → repositorio local. Para registrar un cambio en el historial, primero lo pasas a staging con git add y luego ejecutas git commit. En Jujutsu, el estado de tu copia de trabajo (working copy) es en sí mismo un commit. Desde el punto de vista de Jujutsu, no hay ninguna diferencia entre tu directorio de trabajo y el commit actual. Eso trae varias ventajas prácticas:

Nunca tienes que decidir cuándo guardar en el historial
No necesitas nada parecido a git stash al cambiar de tarea
Es muy poco probable que pierdas el trabajo en curso

Llevar la cuenta de qué archivos no están en staging o todavía no han entrado en un commit es una carga cognitiva que no tiene nada que ver con el trabajo de desarrollo en sí. Lo mismo ocurre con guardar y recuperar stashes cuando algo imprevisto te interrumpe. Jujutsu reduce esos costos casi a cero.

En la programación con IA, con la configuración adecuada, basta con pedirle a un agente «crea la funcionalidad X». El trabajo va quedando en un único commit a medida que avanza, y el agente lo remata con un mensaje como «feat: X». En el flujo normal, no tienes que ocuparte del historial en absoluto.

Casi nunca te pasa el accidente en el que git reset, git clean o un comando de shell borra archivos que ya no puedes recuperar. A mí un agente de IA me ha borrado archivos que no pude recuperar, e incluso ahora, cuando se supone que los modelos son mucho mejores que antes, sigo viendo casos así de vez en cuando. Jujutsu hace commit de la copia de trabajo sobre la marcha¹, así que en la mayoría de los casos cualquier cosa borrada por error se puede recuperar del historial.

Si me viera obligada a volver a Git, tendría que volver a pensar en guardar, y siempre estaría a un comando equivocado de perder el trabajo en curso. Solo de imaginarlo me agoto. Jujutsu reduce la carga cognitiva del control de versiones y me da tranquilidad.

Razón 2: experimentar sale mucho más barato

Ahora que un agente de IA puede construir en un momento lo que le pida, hago mucho más ensayo y error: construir algo, quedármelo si está bien y tirarlo y volver a empezar si no. Hacer eso en Git se complica enseguida. Si experimentas en el working tree sin hacer commit, no tienes salida cuando descartas algo y luego decides que lo querías. Si quieres conservarlo en el historial, necesitas ramas, y crearlas, cambiar entre ellas, fusionarlas y eliminarlas requiere tanto trabajo que experimentar empieza a dar pereza.

¿Y cómo lo resuelve Jujutsu? La unidad básica del historial en Jujutsu, más o menos equivalente a un commit de Git, es el change. Cuando Jujutsu detecta modificaciones en la copia de trabajo, actualiza automáticamente el change actual y conserva también las versiones anteriores. Basta con experimentar dentro de un change. Crea uno nuevo con jj new y prueba lo que quieras. Si te gusta el resultado, dale una descripción (más o menos, un mensaje de commit). Si no, descártalo con jj abandon. Si más adelante lo quieres recuperar, jj operation revert <operation ID> deshace esa operación², y si acabas de borrarlo, basta un jj undo para traerlo de vuelta.

Jujutsu también te permite ramificar el historial desde cualquier punto sin ponerle nombre a nada. Solo tienes que pasarle a jj new el ID del change padre. Para comparar distintos enfoques de la misma tarea, crea varios de estos changes hermanos y muévete entre ellos con jj edit <change ID>. Ponle una descripción al que quieras conservar y haz jj abandon del resto. Eso es todo.

Como el change, la unidad básica del historial de Jujutsu, sirve a la vez de espacio de pruebas, experimentar forma parte del flujo de trabajo normal. No hace falta ningún merge. Y como al empezar un experimento no sabes si saldrá bien, tampoco tienes que ponerle nombre de antemano.

Si me viera obligada a volver a Git, sin duda me costaría más ponerme a experimentar. Ya me veo evitando crear la rama porque resulta tedioso, experimentando en el working tree, tirando algo, queriendo recuperarlo y arrepintiéndome.

Razón 3: reescribir el historial es sencillo e intuitivo

Cuando escribía el código yo misma, lo conocía al dedillo, así que mis commits eran sólidos y rara vez tenía que volver a ellos. Pero casi nadie lee cada línea que genera una IA y la entiende tan bien como su propio código antes de hacer commit. Así que ahora me encuentro queriendo cambiar commits que se suponían terminados mucho más a menudo que antes.

Supón que quieres incorporar un cambio en src/styles/global.css al commit de tres posiciones atrás. ¿Cómo se hace en Git y cómo en Jujutsu? Hay dos maneras de abordarlo: editar directamente el commit en cuestión, o hacer el cambio encima y fusionarlo (squash) con ese commit. Aquí compararé la primera.

Empecemos por Git. No puedes hacerlo con cambios sin commit de por medio, así que, si los tienes, primero debes apartarlos con git stash -u. Después:

git rebase -i HEAD~4

En el editor que se abre, cambia pick por edit en la línea del commit en cuestión y guarda.

- pick bbbbbbb Mensaje del commit B
+ edit bbbbbbb Mensaje del commit B
  pick ccccccc Mensaje del commit C
  pick ddddddd Mensaje del commit D
  pick eeeeeee Mensaje del commit E

Tu working tree está ahora en el commit B. Edita src/styles/global.css y haz commit.

git add src/styles/global.css
git commit --amend --no-edit

Pero no has terminado. Los commits posteriores todavía tienen que volver a aplicarse encima de esa edición. Ejecuta git rebase --continue y reza para que no haya conflictos. Si los hay, el rebase se detiene, y tienes que arreglar los archivos, hacer git add y volver a ejecutar git rebase --continue, tantas veces como haga falta. Si pierdes el hilo, git rebase --abort te devuelve a la casilla de salida. Es agotador.

Ahora lo mismo en Jujutsu. jj edit @--- mueve la copia de trabajo al change de tres posiciones atrás. Edita src/styles/global.css. Jujutsu hace rebase automáticamente de los changes descendientes sobre él, así que, si no hay conflictos, has terminado. Incluso si surge un conflicto, el rebase automático termina sin detenerse. Basta con ir con jj edit al change en conflicto y arreglarlo allí, y el rebase automático vuelve a ejecutarse.

Que haya menos pasos es un buen extra, pero la gran ventaja es que resulta mucho más intuitivo. Vas al punto del historial que te interesa y editas los archivos. Jujutsu se encarga del rebase por su cuenta, así que apenas notas que está ocurriendo. En Git, por alguna razón, el rebase es el protagonista. Empiezas con git rebase y terminas con git rebase. Es contraintuitivo, y los pasos intermedios son tan complicados que nunca llegué a memorizarlos.

Si me viera obligada a volver a Git, probablemente evitaría reescribir el historial siempre que pudiera, por lo complicado del proceso. Se irían acumulando commits de parche, o se colarían cambios sin relación en el primer commit que tuviera a mano, y mi historial sería mucho más difícil de leer.

Razón 4: veo el historial como un grafo, no solo como una línea temporal

Empecemos comparando la salida del comando de log de cada herramienta. La primera es git log; la segunda, jj log. Por defecto, Jujutsu oculta la mayoría de los changes inmutables, así que pasé -r :: para quitar esa limitación.

El log de Git muestra lo que ocurrió en tu rama actual, en orden y en línea recta, como la cronología de un libro de historia. El log de Jujutsu te da una vista panorámica de todo el historial, dibuja las ramificaciones con arte ASCII y concentra más información. De un vistazo captas muchísimo más.

Lo que ocurre al moverte a un punto pasado del historial también es distinto. Ejecuta git checkout <commit ID> en Git, y git log deja de mostrar lo que hay después de ese punto. Ejecuta jj edit <change ID> en Jujutsu, y el log se queda como estaba. Solo la marca @, que representa el commit de la copia de trabajo, se mueve al nodo de ese change.

Estas diferencias en el aspecto y el comportamiento del log dicen mucho de la filosofía de diseño de cada herramienta. En Git, en principio se espera que estés en alguna rama con nombre mientras trabajas, y siempre te empuja hacia la punta de esa única línea del historial. Quizá por eso el log por defecto no se molesta en mostrar dónde estás dentro del historial completo ni lo que ocurre fuera de esa línea³.

Jujutsu no tiene nada que corresponda a las ramas con nombre de Git⁴. Puedes moverte libremente a cualquier nodo editable del historial, esté en la línea que esté. Por eso un grafo del historial completo resulta tan útil.

Reescribir el historial en Jujutsu es fácil, en buena parte, gracias a este log denso y legible. Es como trabajar con un programa de edición de video con una línea de tiempo multipista delante. En comparación, editar el historial en Git se siente como cortar película analógica con tijeras y volver a pegar los trozos.

git log también puede dibujar un árbol en arte ASCII si le pasas --graph, aunque no es tan legible como el de Jujutsu. Pero ver el grafo no te permite editar entre ramas de forma intuitiva y segura como en Jujutsu, así que, aunque volviera a Git, casi no lo usaría.

El lugar de Git hoy

Hace más de seis meses que me pasé por completo a Jujutsu, pero en realidad no he dejado de usar Git. La capa de almacenamiento de Jujutsu admite distintos backends, y puede usar un repositorio Git como backend. Cuando inicializas un repositorio con Jujutsu, por defecto obtienes un colocated workspace, con .git/ y .jj/ uno al lado del otro en la raíz del proyecto. Sigo usando un repositorio Git; simplemente he dejado de usar la interfaz de Git para trabajar con él. El comando git sigue funcionando si lo necesitas.

Gracias a esa compatibilidad, nadie a tu alrededor sabrá que usas Jujutsu a menos que lo digas. En un equipo que use GitHub o GitLab, es perfectamente posible que alguien lleve todo este tiempo usando Jujutsu sin decir nada. En el día a día, casi las únicas veces que pienso en Git son cuando preparo un repositorio con jj git init o jj git clone y, a partir de ahí, cuando sincronizo con el remoto usando jj git fetch y jj git push.

Empecé a usar Git por GitHub, y me pasé a Jujutsu cuando me lancé de lleno a programar con IA. Ya no hay vuelta atrás. Después de tantos años acostumbrada a Git, algunas costumbres de Jujutsu me resultaron raras al principio. Pero si miras la historia del control de versiones, a menudo resulta que el raro era Git, y hoy Jujutsu me parece más natural en la mayoría de las situaciones.

Aun así, Jujutsu sigue siendo minoritario, y me frustra que una herramienta tan buena no sea más conocida. El problema es que es compatible con Git, pero se basa en un modelo mental muy distinto. Si lo pruebas con mentalidad de Git, guiándote por una tabla de equivalencias entre comandos de Git y jj, apenas notarás las ventajas. Por eso escribí una guía de Jujutsu para principiantes pensada para que no te atasques , centrada en ayudarte a adoptar ese nuevo modelo mental.

Juju-chu! —Comienza tu flujo de trabajo Jujutsu × IA con jj new

Una guía práctica para adoptar Jujutsu (jj) junto a Claude Code y Codex: snapshots automáticos, operaciones que siempre se pueden deshacer y una reescritura del historial que es segura.

juju-chu.com

Se titula Juju-chu! —Comienza tu flujo de trabajo Jujutsu × IA con jj new. El libro tiene una portada de estilo novela ligera y un aspecto divertido, pero el contenido va en serio. Lleva paso a paso a quienes empiezan con Jujutsu hasta que pueden usarlo con confianza. Si este artículo despertó tu curiosidad por Jujutsu, échale un vistazo. En la página encontrarás una muestra que puedes leer directamente en tu navegador.

Footnotes

Para ser exactos, cada vez que se ejecuta cualquier comando jj, Jujutsu comprueba si hay diferencias entre la copia de trabajo y el último estado del historial y, si las hay, hace commit. Los agentes de IA a los que se les indica usar Jujutsu suelen revisar su trabajo con jj status o un comando similar en las pausas naturales de una tarea, y es en ese momento cuando se produce el commit. ↩
Aparte del log normal, Jujutsu mantiene un registro de operaciones que recoge cada operación realizada sobre el repositorio. Cada entrada tiene un ID de operación, con el que puedes revertir esa operación o restaurar los archivos tal como estaban justo después de ella. ↩
Me refiero al comportamiento por defecto. Con --all, verás todas las ramas de tu repositorio local y los commits alcanzables desde ellas. ↩
Los bookmarks de Jujutsu se tratan como ramas al trabajar con Git, pero conceptualmente son otra cosa. ↩

15 anos de Git e depois Jujutsu: por que não consigo mais voltar

Yuka Ooka — Mon, 28 Sep 2026 00:00:00 +0000

2026: o primeiro VCS que escolhi de verdade

Olhando para trás, eu nunca cheguei a escolher um sistema de controle de versões (VCS). Usava o que a empresa onde eu trabalhava tivesse adotado. Na maioria dos meus empregos anteriores, usava-se Subversion em um servidor interno. Até que, em 2011, entrei em uma empresa que tinha adotado o GitHub, o que significava que todos os engenheiros precisavam usar Git. Foi aí que comecei a usar Git e GitHub para valer.

Vindo do Subversion, o Git me parecia pouco intuitivo e difícil de usar. O GitHub também trouxe uma nova exigência: deixar o histórico limpo para facilitar a revisão. Os comandos para isso eram inconsistentes e difíceis de memorizar, e cada um vinha com aquela pressão de saber que não dava para errar.

Com o tempo, aquela frustração foi amortecendo e eu aceitei que as coisas eram assim. Mesmo assim, continuava sem conseguir memorizar os comandos. Qualquer coisa um pouco mais complicada exigia uma busca no Google, e eu evitava tudo o que pudesse causar um conflito. Assim se passaram cinco anos, depois dez. Justo quando parecia que os quinze passariam do mesmo jeito, tudo mudou. Chegaram os agentes de IA para programação, como o Claude Code, e, quase sem eu perceber, a IA já escrevia mais código do que humanos. Alguns anos antes, eu não teria acreditado.

Dê instruções a uma IA e ela escreve o código num piscar de olhos. Com tudo andando tão rápido, o ritual trabalhoso de fazer add e depois commit no Git virou um verdadeiro gargalo. Se funcionava, eu fazia o commit por enquanto, mesmo sem ainda entender o código tão a fundo quanto o que eu mesma tinha escrito. E depois, inevitavelmente, queria mudar coisas. Perdia alterações importantes em algum ponto do inferno do rebase, ou desistia e empilhava commits de remendo por cima até o histórico virar uma bagunça. Isso passou a fazer parte do dia a dia.

Foi então que encontrei o Jujutsu. No Japão, por volta de janeiro de 2026, uma leva de artigos introdutórios circulou bastante, e a comunidade de desenvolvedores em geral começou a prestar atenção nele. Depois de ler alguns, achei que ele combinaria bem com a programação com IA e o experimentei em um projeto em que eu estava trabalhando. A filosofia de design e os comandos são tão diferentes dos do Git que, no começo, tive muita dificuldade para usá-lo. O que me impediu de desistir foi a simplicidade de trabalhar sem staging area e a tranquilidade de saber que qualquer operação podia ser desfeita. Depois de mais ou menos um mês, eu já conseguia usá-lo razoavelmente bem.

Desde então, gerencio todos os meus repositórios com o Jujutsu, e também escrevo tudo com ele, de posts de blog e documentação a manuscritos de livros (este post incluído, claro). Pensando bem, trocar o Git pelo Jujutsu foi a primeira vez que escolhi um VCS por conta própria. E, em algum momento, percebi que não conseguia mais voltar ao Git. Estas são, na minha visão, as razões pelas quais não tenho a menor vontade de voltar.

Razão 1: nunca preciso me perguntar se meu trabalho está salvo

O Git usa um modelo de três estados: working tree → índice → repositório local. Para registrar uma alteração no histórico, primeiro você a coloca em staging com git add e depois executa git commit. No Jujutsu, o estado da sua cópia de trabalho (working copy) já é, em si, um commit. Do ponto de vista do Jujutsu, não existe diferença entre o seu diretório de trabalho e o commit atual. Isso traz algumas vantagens práticas:

Você nunca precisa decidir quando salvar no histórico
Você não precisa de nada parecido com git stash ao trocar de tarefa
É muito improvável que você perca trabalho em andamento

Controlar quais arquivos ainda não estão em staging ou ainda não entraram em um commit é uma carga cognitiva que não tem nada a ver com o trabalho de desenvolvimento em si. O mesmo vale para guardar e recuperar stashes quando algo inesperado interrompe você. O Jujutsu reduz esses custos a quase zero.

Na programação com IA, com a configuração certa, basta pedir a um agente “crie a funcionalidade X”. O trabalho vai sendo registrado em um único commit à medida que avança, e o agente o finaliza com uma mensagem como “feat: X”. No fluxo normal, você não precisa cuidar do histórico em nenhum momento.

Você também quase nunca passa pela situação de ver git reset, git clean ou um comando do shell apagar arquivos que não dá mais para recuperar. Eu mesma já tive arquivos apagados por um agente de IA sem conseguir recuperá-los e, mesmo hoje, com modelos supostamente muito melhores do que antes, ainda vejo relatos assim de vez em quando. O Jujutsu faz commit da cópia de trabalho conforme você trabalha¹, então, na maioria dos casos, qualquer coisa apagada por engano pode ser recuperada do histórico.

Se eu fosse obrigada a voltar ao Git, teria que voltar a pensar em salvar, e estaria sempre a um comando errado de perder o trabalho em andamento. Só de imaginar, já fico cansada. O Jujutsu reduz a carga cognitiva do controle de versões e me dá tranquilidade.

Razão 2: experimentar fica muito mais barato

Agora que um agente de IA consegue construir em instantes o que eu pedir, faço muito mais tentativa e erro: construir algo, ficar com o resultado se estiver bom e jogar fora e recomeçar se não estiver. Fazer isso no Git logo fica complicado. Se você experimenta na working tree sem fazer commit, fica sem saída quando descarta algo e depois decide que queria aquilo. Se quiser guardar no histórico, precisa de branches, e criá-los, alternar entre eles, fazer merge e apagá-los dá tanto trabalho que experimentar começa a dar preguiça.

E como o Jujutsu resolve isso? A unidade básica do histórico no Jujutsu, mais ou menos equivalente a um commit do Git, é o change. Quando o Jujutsu detecta edições na cópia de trabalho, ele atualiza automaticamente o change atual e também guarda as versões anteriores. Basta experimentar dentro de um change. Crie um novo com jj new e teste o que quiser. Se gostar do resultado, dê a ele uma descrição (mais ou menos, uma mensagem de commit). Se não gostar, descarte-o com jj abandon. Se depois quiser recuperá-lo, jj operation revert <operation ID> desfaz essa operação² e, se você acabou de descartá-lo, um único jj undo o traz de volta.

O Jujutsu também permite criar ramificações a partir de qualquer ponto do histórico sem dar nome a nada. Basta passar o ID do change pai para jj new. Para comparar abordagens diferentes para a mesma tarefa, crie vários desses changes irmãos e alterne entre eles com jj edit <change ID>. Dê uma descrição ao que quiser manter e faça jj abandon do resto. Só isso.

Como o change, a unidade básica do histórico do Jujutsu, também serve de área de testes, experimentar passa a fazer parte do fluxo de trabalho normal. Não é preciso fazer merge. E como, ao começar um experimento, você não sabe se ele vai dar certo, também não precisa dar nome a ele de antemão.

Se eu fosse obrigada a voltar ao Git, com certeza teria mais resistência a experimentar. Já me vejo deixando de criar o branch pelo trabalho que dá, experimentando na working tree, jogando algo fora, querendo recuperar e me arrependendo.

Razão 3: reescrever o histórico é simples e intuitivo

Quando eu mesma escrevia o código, eu o conhecia de trás para a frente, então meus commits eram sólidos e raramente eu precisava voltar a eles. Mas quase ninguém lê cada linha que uma IA gera e a entende tão bem quanto o próprio código antes de fazer commit. Por isso, hoje me pego querendo alterar commits supostamente prontos com muito mais frequência do que antes.

Suponha que você queira incluir uma alteração em src/styles/global.css no commit de três posições atrás. Como isso fica no Git e no Jujutsu? Há duas formas de fazer isso: editar diretamente o commit em questão ou fazer a alteração por cima e incorporá-la (squash) a esse commit. Aqui vou comparar a primeira.

Vamos começar pelo Git. Não dá para fazer isso com alterações sem commit no caminho, então, se houver alguma, primeiro você precisa guardá-las com git stash -u. Depois:

git rebase -i HEAD~4

No editor que se abre, troque pick por edit na linha do commit em questão e salve.

- pick bbbbbbb Mensagem do commit B
+ edit bbbbbbb Mensagem do commit B
  pick ccccccc Mensagem do commit C
  pick ddddddd Mensagem do commit D
  pick eeeeeee Mensagem do commit E

Agora sua working tree está no commit B. Edite src/styles/global.css e faça o commit.

git add src/styles/global.css
git commit --amend --no-edit

Mas ainda não acabou. Os commits seguintes ainda precisam ser reaplicados sobre essa edição. Execute git rebase --continue e reze para não haver conflito. Se houver, o rebase para, e você precisa corrigir os arquivos, fazer git add e executar git rebase --continue de novo, quantas vezes forem necessárias. Se você se perder no meio do caminho, git rebase --abort leva você de volta à estaca zero. É cansativo.

Agora, a mesma coisa no Jujutsu. jj edit @--- move a cópia de trabalho para o change de três posições atrás. Edite src/styles/global.css. O Jujutsu faz automaticamente o rebase dos changes descendentes sobre ele, então, se não houver conflitos, pronto. Mesmo que surja um conflito, o rebase automático termina sem parar. Basta ir com jj edit até o change em conflito e corrigi-lo ali, e o rebase automático é executado de novo.

Ter menos passos é um bônus, mas a grande vantagem é que tudo fica muito mais intuitivo. Você vai até o ponto do histórico que interessa e edita os arquivos. O Jujutsu cuida do rebase por conta própria, então você mal percebe que ele está acontecendo. No Git, por algum motivo, o rebase é o protagonista. Você começa com git rebase e termina com git rebase. É contraintuitivo, e os passos intermediários são tão trabalhosos que nunca consegui memorizá-los.

Se eu fosse obrigada a voltar ao Git, provavelmente evitaria reescrever o histórico sempre que pudesse, por causa do trabalho que dá. Commits de remendo se acumulariam, ou alterações sem relação acabariam enfiadas em qualquer commit que estivesse à mão, e meu histórico ficaria muito mais difícil de ler.

Razão 4: vejo o histórico como um grafo, não só como uma linha do tempo

Vamos começar comparando a saída do comando de log de cada ferramenta. A primeira é do git log; a segunda, do jj log. Por padrão, o Jujutsu oculta a maioria dos changes imutáveis, então passei -r :: para remover essa limitação.

O log do Git mostra o que aconteceu no seu branch atual, em ordem e em linha reta, como a cronologia de um livro de história. O log do Jujutsu oferece uma visão panorâmica de todo o histórico, desenha as ramificações com arte ASCII e concentra mais informação. Num relance, você absorve muito mais.

O que acontece quando você vai para um ponto passado do histórico também é diferente. Execute git checkout <commit ID> no Git, e o git log deixa de mostrar o que vem depois desse ponto. Execute jj edit <change ID> no Jujutsu, e o log continua como estava. Só a marca @, que representa o commit da cópia de trabalho, se move para o nó desse change.

Essas diferenças na aparência e no comportamento do log dizem muito sobre a filosofia de design de cada ferramenta. No Git, em princípio, espera-se que você esteja em algum branch com nome enquanto trabalha, e você está sempre sendo empurrado para a ponta dessa única linha do histórico. Talvez seja por isso que o log padrão nem se dá ao trabalho de mostrar onde você está no histórico como um todo nem o que acontece fora dessa linha³.

O Jujutsu não tem nada que corresponda aos branches com nome do Git⁴. Você pode ir livremente para qualquer nó editável do histórico, esteja ele na linha que estiver. É por isso que um grafo do histórico completo é tão útil.

Reescrever o histórico no Jujutsu é fácil, em boa parte, graças a esse log denso e legível. É como trabalhar em um programa de edição de vídeo com uma linha do tempo de várias trilhas à sua frente. Em comparação, editar o histórico no Git parece cortar filme analógico com tesoura e colar os pedaços de volta.

O git log também consegue desenhar uma árvore em arte ASCII se você passar --graph, embora não seja tão legível quanto a do Jujutsu. Mas ver o grafo não permite editar entre branches de forma intuitiva e segura como no Jujutsu, então, mesmo que eu voltasse ao Git, quase não o usaria.

O lugar do Git hoje

Já faz mais de seis meses que migrei totalmente para o Jujutsu, mas, na verdade, não parei de usar o Git. A camada de armazenamento do Jujutsu é plugável, e ele pode usar um repositório Git como backend. Quando você inicializa um repositório com o Jujutsu, por padrão obtém um colocated workspace, com .git/ e .jj/ lado a lado na raiz do projeto. Continuo usando um repositório Git; só deixei de usar a interface do Git para trabalhar com ele. O comando git continua funcionando, se você precisar.

Graças a essa compatibilidade, ninguém ao seu redor vai saber que você usa o Jujutsu, a menos que você conte. Em uma equipe que usa GitHub ou GitLab, é perfeitamente possível que alguém esteja usando o Jujutsu discretamente esse tempo todo. No dia a dia, praticamente as únicas vezes em que penso no Git são quando preparo um repositório com jj git init ou jj git clone e, a partir daí, quando sincronizo com o remoto usando jj git fetch e jj git push.

Comecei a usar o Git por causa do GitHub e troquei pelo Jujutsu quando mergulhei de vez na programação com IA. Agora não tem mais volta. Depois de tantos anos acostumada ao Git, alguns jeitos do Jujutsu me pareceram estranhos no começo. Mas, olhando para a história do controle de versões, muitas vezes o estranho era o Git, e hoje o Jujutsu me parece mais natural na maioria das situações.

Ainda assim, o Jujutsu continua sendo pouco conhecido, e me frustra que uma ferramenta tão boa não tenha mais visibilidade. O problema é que ele é compatível com o Git, mas se baseia em um modelo mental muito diferente. Se você o experimentar com a cabeça no Git, guiando-se por uma tabela de equivalência entre comandos do Git e do jj, mal vai notar as vantagens. Por isso escrevi um guia de Jujutsu para iniciantes pensado para você não travar no caminho , centrado em ajudar você a adotar esse novo modelo mental.

Juju-chu! — Comece seu fluxo de trabalho Jujutsu × IA com jj new

Um guia prático para adotar Jujutsu (jj) com Claude Code e Codex: snapshots automáticos, operações que podem ser desfeitas e reescrita segura do histórico.

juju-chu.com

Ele se chama Juju-chu! — Comece seu fluxo de trabalho Jujutsu × IA com jj new. O livro tem uma capa no estilo light novel e um visual divertido, mas o conteúdo é sério. O livro orienta você passo a passo, desde os primeiros contatos com o Jujutsu até você conseguir usá-lo com confiança. Se este post despertou sua curiosidade pelo Jujutsu, dê uma olhada. Na página, você encontra uma amostra que pode ler diretamente no navegador.

Footnotes

Para ser exata, sempre que qualquer comando jj é executado, o Jujutsu verifica se há diferenças entre a cópia de trabalho e o estado mais recente do histórico e, se houver, faz o commit. Agentes de IA instruídos a usar o Jujutsu costumam conferir o próprio trabalho com jj status ou um comando parecido nas pausas naturais de uma tarefa, e é nesse momento que o commit acontece. ↩
Além do log normal, o Jujutsu mantém um registro de operações com cada operação realizada no repositório. Cada entrada tem um ID de operação, que você pode usar para reverter essa operação ou restaurar os arquivos como estavam logo depois dela. ↩
Refiro-me ao comportamento padrão. Com --all, você vê todos os branches do seu repositório local e os commits alcançáveis a partir deles. ↩
Os bookmarks do Jujutsu são tratados como branches ao trabalhar com o Git, mas, conceitualmente, são outra coisa. ↩