DEV Community: Juju-chu! Blog (es)

¿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” ↩

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 ↩

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