Introducción a Jujutsu
¿Qué es Jujutsu?
Jujutsu (comando jj) es un sistema de control de versiones creado en Google por Martin von Zweigbergk. Su objetivo es ofrecer una experiencia más intuitiva y segura que Git, manteniendo compatibilidad total con repositorios Git.
No es un wrapper sobre Git — es un VCS completo con su propio modelo de datos que puede usar Git como backend de almacenamiento.
Diferencias clave con Git
| Concepto | Git | Jujutsu |
|---|---|---|
| Staging area | git add para seleccionar cambios | No existe. El working copy es un commit |
| Estado de trabajo | Cambios sin trackear, staged, committed | Todo es un commit automáticamente |
| Deshacer | git reflog + comandos variados | jj undo para cualquier operación |
| Conflictos | Bloquean merge/rebase hasta resolverlos | Se almacenan en el árbol, puedes seguir trabajando |
| Ramas | Referencias mutables (branches) | Bookmarks (punteros a commits) |
| Editar historial | git rebase -i (interactivo) | jj squash, jj split, jj edit (directos) |
| Descendientes | Debes hacer rebase manual | Se actualizan automáticamente |
El modelo mental de jj
En Git piensas en 3 estados: working directory, staging area, commits. En jj solo hay commits:
Git: Working Dir → Staging → Commit
Jujutsu: Working Copy (ya es un commit)
Cuando modificas un archivo, jj actualiza el commit del working copy automáticamente. No necesitas add ni stage.
¿Cuándo elegir jj sobre Git?
- Quieres editar el historial frecuentemente (rebase, squash, split)
- Te frustra el staging area de Git
- Trabajas con conflictos frecuentes (monorepos, ramas largas)
- Quieres experimentar sin miedo a perder trabajo
- Ya usas Git y quieres una mejor interfaz sin migrar
¿Cuándo NO usar jj?
- Tu equipo no está dispuesto a aprender una herramienta nueva
- Necesitas soporte nativo en IDEs (aún limitado)
- Dependes de Git hooks complejos
jj es compatible con Git — puedes usarlo en repos Git existentes sin que tus compañeros noten la diferencia.