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

DEV Community: Juju-chu! Blog (es)