DEV Community: Yuka Ooka

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