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

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:

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:

1. 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
2. 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
3. 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.