Jujutsu para todos

• Este documento es un tutorial para principiantes que enseña Jujutsu (VCS) paso a paso con una estructura por niveles, de modo que se pueda seguir incluso sin experiencia con Git
• Asume el uso de terminal, pero también cubre desde los fundamentos de la terminal; los comandos principales se explican principalmente para Linux/macOS y para usuarios de Windows se recomienda WSL
• El flujo de aprendizaje está estructurado para afianzar lo básico, la colaboración y la resolución de problemas en los niveles 1 a 3, y luego expandirse en niveles superiores hacia reescritura de historial y flujos de trabajo avanzados
• Para cuando el estado se desordene durante el tutorial, ofrece un entorno de aprendizaje reproducible que permite volver al inicio de cada capítulo con un script de reset
• Sobre por qué usar Jujutsu en lugar de Git, presenta como fundamentos la compatibilidad con Git, la reducción de la dificultad de aprendizaje y las funciones avanzadas; además, se está actualizando con base en Jujutsu 0.32

---

Introducción (Introduction)

• Este tutorial es un material introductorio dirigido a usuarios que usan Jujutsu por primera vez
• Ofrece contenido centrado en principiantes para complementar la limitación de los materiales existentes de Jujutsu, que se enfocaban en la transición de usuarios expertos de Git
• El uso de terminal es la base, incluye un capítulo de uso básico de terminal y recomienda usar WSL para usuarios de Windows

Cómo leer este tutorial (How to read this tutorial)

• El contenido está organizado por niveles, y el aprendizaje está diseñado para que, tras completar cada nivel, practiques de verdad antes de pasar al siguiente
• Si tu objetivo es la colaboración, se recomienda tomar seguidos los niveles 1 y 2
• Resumen de niveles
  • Nivel 1: ofrece el conjunto mínimo para empezar con trabajo individual; adecuado para alguien como un estudiante que gestiona tareas por su cuenta
  • Nivel 2: el conjunto mínimo para colaborar, necesario para proyectos de equipo estudiantiles y desarrolladores en entornos reales
  • Nivel 3: bases de resolución de problemas como manejo de conflictos y recuperación; corresponde al nivel promedio de experiencia de un desarrollador
  • Nivel 4: construir un historial limpio mediante reescritura de historial, necesario para cumplir los estándares de calidad de algunos proyectos
  • Nivel 5: impulsores de productividad, flujos de trabajo avanzados, CLI esotérica y teoría; la etapa de maestría en Jujutsu
  • Nivel 6: temas según el contexto como tags, submódulos y workspaces; se recomienda consultarlo cuando haga falta

Atajos de teclado (Keyboard shortcuts)

• Soporta moverse entre capítulos con las flechas izquierda y derecha
• Soporta búsqueda dentro del libro con S o /
• Muestra ayuda con ? y permite ocultarla con Esc

Restablece tu progreso (Reset your progress)

• Como el estado del repositorio de ejemplo está conectado con el siguiente capítulo, perder ese estado puede bloquear el avance
• Para resolverlo, se proporciona un script reset.sh que restaura el punto de inicio del capítulo
• Al inicio de cada capítulo se incluye el comando exacto de reset, para que el entorno pueda reproducirse con copiar y pegar
• Se recomienda revisar el contenido del script antes de ejecutarlo; en la práctica, su comportamiento es simple, al nivel de una colección de comandos manuales
• Características principales del script
  • Bloquea el impacto de la configuración del usuario con JJ_CONFIG=/dev/null
  • Crea el repositorio de ejemplo, reconstruye la integración colocada con Git, la configuración de usuario y escenarios encadenados como commit/push/fetch/rebase
  • Está diseñado para recibir como argumento la palabra clave de cada capítulo y bifurcarse para terminar correctamente en ese punto

Mantente al día (Stay up to date)

• Tanto el tutorial como Jujutsu siguen evolucionando, y puedes recibir avisos de cambios importantes suscribiéndote a Releases del repositorio del tutorial
• Se indica que este tutorial está actualizado con base en Jujutsu 0.32 (agosto de 2025)
• También ofrece instrucciones para configurar notificaciones de actualización en GitHub con Watch → Custom → Releases

La necesidad del control de versiones (What is version control and why use it?)

• Es un medio para gestionar la acumulación gradual del trabajo, aplicable no solo al software sino también a la redacción de documentos como Typst
• Permite volver a estados anteriores y soporta de forma segura el trabajo simultáneo de varias personas
• Jujutsu es adecuado cuando se necesitan herramientas de control más precisas que un respaldo común o un editor colaborativo

Por qué Jujutsu (Why Jujutsu instead of Git?)

• Compatibilidad con Git: permite interoperabilidad sin pérdidas con repositorios Git existentes y aprovechar tal cual la mayoría de las herramientas integradas con Git
• Facilidad de aprendizaje: frente a la interfaz compleja y poco intuitiva de Git, Jujutsu ofrece la misma funcionalidad con menor complejidad
• Funciones más potentes: además de ser fácil de aprender, ofrece muchas funciones para usuarios avanzados, lo que garantiza la expansión del flujo de trabajo
• Desventajas y consideraciones
  • En la conversación cotidiana existe la carga de mapear conceptos frente a una cultura centrada en la terminología de Git, aunque esto puede aliviarse convenciendo a colegas
  • Al ser relativamente nuevo, hay casos donde faltan algunas funciones de Git; si hace falta, se puede recurrir directamente a Git como alternativa
  • La CLI aún está en proceso de estabilización, así que algunos comandos pueden cambiar; se recomienda suscribirse a los lanzamientos del tutorial para seguir esos cambios

Progreso del aprendizaje (Completed & Next)

• Actualmente está estructurado principalmente alrededor de los niveles 1 a 3, para interiorizar un flujo práctico de tareas (instalación → inicialización → log/commit → remoto/push·clone → branch/merge → rebase → navegación → revertir/recuperar → resolución de conflictos → limpieza)
• En niveles superiores propone una estrategia de dominio gradual para seguir aprendiendo sobre reescritura, flujos de trabajo avanzados y temas poco comunes

[GN⁺]

Opiniones de Hacker News

• Siento que he visto decenas de artículos elogiando a jj. Este tutorial va por la misma línea, pero a estas alturas ya he leído suficiente sobre lo bueno y me interesan más las desventajas y lo incómodo. Cuando probé jj, le vi pros y contras. Suelo usar mucho un flujo de trabajo donde comparto ramas con colegas y seguimos apilando commits, y con jj me resultó más engorroso que con git porque no hay ramas con nombre así nada más (incluso usando el alias tug). La sección “Tracking remote bookmarks” del tutorial también me sigue pareciendo incómoda. Otra cosa que me molestó es que jj no puede usar clones ligeros como git clone --filter=blob:none de git; me pregunto si eso ya se arregló

  • jj sí tiene ramas con nombre, pero en jj se llaman “bookmarks”. Si rastreas un remote bookmark, tu copia local se sincroniza con el remoto usando jj git fetch

  • Una de las cosas que me complicó fue que a veces jj parecía perder mis cambios de forma aleatoria. Estaba trabajando en Cursor y no había mutado el repo con jj (solo había hecho cosas como jj status o jj log), pero después veía que mis cambios habían desaparecido, y a veces salía el mensaje "stale workspace". No sé si fue por el IDE o por un monorepo gigantesco, pero de verdad fue doloroso. Aun así, me gusta bastante la flexibilidad de jj

  • En https://github.com/jj-vcs/jj/discussions/3549 hay una discusión sobre cómo hacer el flujo de trabajo de tug un poco más simple

  • Es incorrecto decir que jj no tiene ramas con nombre. Hay que asignarlas manualmente con algo como jj branch set -r@ XYZ, así que es un poco incómodo, pero solo se hace una vez al hacer push. O también puedes mover la rama con jj git push --named XYZ=@

  • Sigue sin resolverse que jj no soporte clones ligeros (git clone --filter=blob:none)

• Dicen que “Jujutsu es más poderoso que Git”, pero no explican en qué sentido exactamente, así que me pregunto por qué debería usarlo. Suena a pura frase de marketing

  • Soy el autor del tutorial. Como está dirigido a principiantes, no me parecía apropiado hacer una comparación detallada con Git. Muchas veces la complejidad de la UI de Git se justifica por su “poder”, así que quise agregar al menos esa afirmación para que la gente supiera que con Jujutsu no pierde capacidades solo por ser más fácil de aprender

  • Por ejemplo, creas una rama nueva desde Main y planeas mandarla luego como PR. Vas acumulando varios commits y luego sientes que necesitas cambiar el commit 1; editas el 1, guardas, y todos los demás commits se rebasingean automáticamente al estado más reciente. Incluso después del PR, si quieres modificar el commit 3, solo editas ese commit y haces push, y ya. Hacer esto directamente en Git es realmente difícil. A mis colegas les encantan los PR divididos en varios commits

  • Yo pienso parecido. En general siento que las UI de Git se quedan cortas, así que estoy dispuesto a usar jj confiando un poco en él. Pero me gustaría ver demostraciones concretas de “por qué es más fácil, más poderoso o más conveniente”

  • Un ejemplo es que puedes registrar un merge conflict como un solo elemento y resolverlo después: https://jj-vcs.github.io/jj/latest/conflicts/

• Volví a probar JJ recientemente y ha mejorado mucho, así que lo estoy usando con gusto. Cuando lo intenté al principio tenía demasiadas asperezas y me intimidaba, pero creo que JJ es parte de una nueva ola excelente de tooling reciente. También escribí sobre eso en mi blog: https://pdx.su/blog/2025-08-13-the-quiet-software-tooling-renaissance/

  • Buen artículo. Creo que en estos últimos años el estándar del tooling para desarrollo realmente ha subido mucho. Rust también es parte de ese cambio

  • Me da gusto ver que tú también usas y te gusta mise. mise, jj (y el TUI totalmente increíble jjui), y uv para Python, todos son revolucionarios. De verdad me parecen herramientas hermosas

  • Yo definitivamente agregaría nushell a esa lista

  • Bun también va al frente de esta revolución del tooling

• ¡Excelente trabajo! Llevo casi 5 meses usando solo Jujutsu y en la práctica ya reemplazó por completo a git para mí. De hecho, en ese tiempo ejecuté Git 52 veces (11 de ellas fueron --help), mientras que Jujutsu lo usé 582 veces. Sin obligarte a adaptarte a un flujo de trabajo específico, Jujutsu es lo bastante flexible para soportar casi cualquiera. Incluso usándolo “como git”, puedes mover commits y ramas libremente (sin necesidad de stash), hacer rebase de forma sencilla (quizá esto sea normal para expertos en git, pero agradezco muchísimo poder hacerlo sin depender de las herramientas de git de VSCode), y concentrarte en el trabajo sin las partes fastidiosas típicas de un VCS. Lo importante es que el historial también sigue quedando en el repo git de siempre, así que sigue siendo compatible con otras herramientas de git. Es decir, yo puedo usar algo distinto sin que mis compañeros tengan que cambiar de VCS. Hay algunos puntos flojos con tags, submodules y LFS, pero aun así vale totalmente la pena probarlo

  • Me pregunto cuál es el equivalente en jj para git branch --set-upstream-to

  • Si pruebas jjui, casi no vas a volver a tocar comandos de jj. Es una locura

• Jujutsu está muy bien. Lo probé hace unos meses y escribí algunos posts al respecto (este, por ejemplo); desde entonces lo he seguido usando. En general es una experiencia muy “coherente”. Yo en realidad ya me manejaba bien con git, pero en jj todo gira alrededor de unos pocos principios básicos, y puedes combinarlos como quieras para hacer fácilmente cambios complejos en el historial. Antes yo trabajaba mucho con “stash”, y jj se siente muchísimo más cómodo que git gracias al seguimiento automático de cambios, al movimiento libre de cambios, etc. El rebase y la resolución de conflictos también son mucho mejores (sobre todo en un flujo estilo stash). Lo recomiendo mucho y el esfuerzo para cambiarse es muy pequeño

• Personalmente no me convence el enfoque de agregar una nueva capa encima de git. Entiendo que es difícil romper la hegemonía de git, pero creo que construir sobre una base totalmente nueva sería mucho más poderoso y libre

• Usé jj como un mes y luego tuve que volver a git por un proyecto específico en el trabajo. Me gustó muchísimo jj, pero no más que eso. Sin embargo, a las pocas horas de haber vuelto a git, ya extrañaba muchísimo lo conveniente que era jj: https://blog.nawaz.org/posts/2025/Aug/the-jujutsu-effect/

  • Me pregunto qué significa exactamente eso de “pero no más que eso”

  • Que no aprecias realmente lo que vale hasta que lo pierdes

• Me gustaría leer más sobre “Jutustsu for Git experts”. Por ejemplo, me pregunto si commitear conflictos no arruinaría mi git rerere, o si hay una forma cómoda en jj de implementar conjuntos de parches en dos etapas, ya que en git me gusta trabajar haciendo staging solo de partes del parche con git add -p. Quiero evitar corrupción de timestamps o rebuilds inútiles del sistema de build

  • Respondo desde el flujo de trabajo más usado en jj (el “squash workflow”). Haces cambios libremente en el top commit, que es tu directorio de trabajo, y cuando quieres “staging”, haces squash hacia abajo al commit inferior (o sea, al de un nivel debajo), ya sea de todos los cambios o solo algunos con -i. También puedes usar squash --into para elegir otro commit y hacer squash exactamente donde quieras

  • 1. jj no usa git rerere, así que la pregunta se desvía un poco. 2. @ es tu workspace, y @- es el commit en el que estás trabajando. Con jj squash -i puedes devolver interactivamente a @ cualquier parte del diff que quieras

  • Aunque estoy de acuerdo con que “la distinción stage/unstage es innecesaria”, me llama la atención ver a alguien decir “me encanta hacer staging solo de las partes que me gustan del patch”. Puedes lograr algo parecido sin staging usando una combinación de git worktree, git diff, vi y git apply, pero es realmente engorroso. Incluso Mercurial 7.1 sigue sin tener agregado interactivo, así que fuera de trucos con worktree no hay muchas alternativas

• Últimamente he visto hablar de Jujutsu, pero no me he metido hasta workflows concretos. Me pregunto si Jujutsu tiene alguna ventaja particular frente a Emacs Magit. La mayoría de las UI de Git que he probado me han parecido flojas, pero Magit me disparó la productividad con git y me hizo sentir la “magia” de git. No sé si Jujutsu busca competir con esa experiencia o si su objetivo es más bien ser una alternativa a las UI tradicionales de git, que sí suelen ser bastante deficientes

  • Jujutsu no es solo una UI para git; de hecho, como UI de git es más bien flojo (le faltan cosas como soporte para tags, submodules, etc.). Es un VCS completamente nuevo que usa git como backend. Si git trajo “cheap branch” frente a SVN, JJ trae “cheap rebase”. Los conflictos no detienen por completo tu flujo de trabajo, y el rebase, la gestión de la estructura de commits, etc., son realmente cómodos. Si ya has usado stacked diffs, te resultará familiar, y los PR con stacked diffs en jj salen casi sin esfuerzo

  • Si ya usas mucho Magit, probablemente también te atraigan los conceptos básicos de jj. jj permite acrobacias con commits que antes parecían imposibles (por ejemplo, rebasing de 2 hojas de un merge octopus de 5 vías dejando conflictos sin resolver). De hecho, es una técnica que desarrollé yo y llamé “Mega Merge”. Magit y jj tienen algo en común: creo que la “magia de git” en realidad proviene del “lenguaje de diseño” de la herramienta. Git es solo la capa física de almacenamiento tanto para Magit como para jj, pero hay diferencias enormes en algoritmos, UX y conceptos. Los usuarios de Magit suelen sorprenderse menos con jj, pero los usuarios avanzados de Git en línea de comandos se pasan a jj con muchísima facilidad y terminan convirtiéndose en verdaderos evangelizadores. Son quienes mejor entienden el poder de una herramienta fuerte para manipular grafos de commits. Por cierto, soy uno de los maintainers de jj y me parece una herramienta muy bien hecha. Ojalá la probaras unos días sin Magit

  • Aquí hay enlaces relacionados. Un post que explica bien el workflow de Megamerge: https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/, https://ofcr.se/jujutsu-merge-workflow, y el mejor TUI de alto nivel alrededor del CLI de jj: https://github.com/idursun/jjui

  • Me pregunto cuál es el “concepto central” de Jujutsu. Considerando que Git es el estándar de la industria, no me queda claro cuál sería la razón de peso para usar Jujutsu. Me parecen ideas interesantes, pero si tuviera una propuesta más clara desde el punto de vista de marketing, tal vez tendría más posibilidades de adopción. La mayor debilidad de Git es lo poco amigable que es para gente externa (terminología, poca facilidad de descubrimiento, falta de buenos frontends GUI, etc.), así que creo que hay mucho potencial en un VCS más amigable para principiantes

  • Me cambié de Magit a jujutsu. Lo que cambió fue que apilar PR se volvió mucho más fácil, y ahora tengo el hábito de dividir cambios en unidades más pequeñas, así que mi criterio de qué “vale la pena enviar” se volvió más estricto. En general ha sido una experiencia positiva, pero si Magit ya te funciona muy bien, no hay una ventaja especial. Aun así, con https://github.com/bolivier/jj-mode.el se puede usar jj perfectamente dentro de Emacs

• Me pareció interesante. Y eso que estoy muy activo en línea, pero es la primera vez que oigo hablar de Jujutsu. Me gusta la idea de ofrecer un VCS mejor usando Git como backend. Una razón es que así todavía puedes respaldar y compartir con Github-Gitlab. Fossil o Bitkeeper también me parecen atractivos, pero no son lo bastante mejores que git como para superar el efecto de red que tiene git. Voy a trastear un poco con Jujutsu. No sé si me quedaré usándolo, pero ojalá resulte mejor de lo que imagino