Tutorial de Jujutsu por Evan

• Un tutorial diseñado para que quienes ya usan Git puedan aprender de forma concisa Jujutsu (jj), un sistema de control de versiones simple pero potente
• Para quienes quieran entender por qué usar Jujutsu antes de empezar, también ofrece un artículo de introducción a Jujutsu por separado
• También recomienda alternativas según el nivel del lector, como una guía introductoria en tono conversacional, documentación oficial detallada y materiales para principiantes absolutos en control de versiones
• Evan Martin lo escribió personalmente para decidir con cuidado qué temas incluir, cuáles omitir y en qué orden presentarlos
• No se usó IA para escribir el contenido principal; después de completar la mayor parte, solo se utilizó IA para revisar errores

---

Público objetivo y ruta de aprendizaje

• Jujutsu es un sistema de control de versiones simple pero potente, y en el tutorial se lo abrevia como jj
• Está dirigido a lectores familiarizados con Git y ofrece un recorrido de aprendizaje conciso enfocado en lo esencial
• Si quieres empezar de inmediato, puedes ir a Comenzar el tutorial; si prefieres ver primero por qué usarlo, consulta el artículo de introducción a Jujutsu

Recursos alternativos según el lector

• Si este enfoque de tutorial no es para ti, puedes elegir entre los siguientes recursos según tu nivel de experiencia y preferencias
  • Steve's Jujutsu tutorial: el recurso introductorio más recomendado, con un estilo conversacional
  • Jujutsu documentation: ofrece un tutorial oficial que entra en más detalles desde el principio
  • Jujutsu for Everyone: pensado para personas sin experiencia previa en control de versiones

Redacción directa y alcance del uso de IA

• Todo el texto fue escrito directamente por Evan Martin, y una persona decidió cuidadosamente qué incluir o excluir y en qué orden presentarlo
• No se usó IA para redactar el contenido principal; solo se utilizó después de escribir la mayor parte para revisar errores

[GN⁺]

Opiniones en Lobste.rs

• Si soy totalmente honesto y pongo en juego mi reputación, probé jj como por una semana, pero al final terminé pidiéndole ayuda a un LLM para reducir el dolor de lidiar directamente con Git, y tampoco sentí que reemplazara suficientemente mi flujo de trabajo actual
  Normalmente solo uso git checkout, git add, git commit, git push, y casi nunca me topo con los problemas del índice, el stash, los distintos tipos de reset, un rebase en curso o los deshacer inconsistentes que mencionan en los textos promocionales; tampoco suelo trabajar con monorepos
  Me da curiosidad saber quién es el público objetivo principal de Jujutsu y cuánto tiempo les tomó volverse competentes con jj; la próxima vez quisiera al menos invertirle ese tiempo

  • Me da curiosidad qué tareas específicas le pides al LLM que te ayude a hacer
    Yo también tiendo a evitar todo lo que vaya más allá de lo básico en Git, así que en vez de hacer stash y cambiar de rama, volvía a clonar el repositorio en otra ubicación, y en vez de seleccionar solo los cambios relacionados para hacer commit, hacía commit de todo con git add --all o revertía cambios en el editor, hacía el commit y luego los aplicaba otra vez
    En el trabajo usé Mercurial durante 7 años, así que tenía un contexto que me facilitó adaptarme a jj, pero ahora reacomodar commits y manejar varios cambios se volvió tan simple que hago activamente tareas complejas que antes habría evitado por instinto
  • La perspectiva cambia según para qué uses un sistema de control de versiones (VCS)
    Si solo desarrollas código de forma lineal y de vez en cuando dejas un snapshot, esos comandos bastan, y un VCS completo puede ser excesivo; incluso Dropbox podría ser suficiente
    Para mí, un VCS es una herramienta para construir una narrativa que muestra cómo pensé el código y su jerarquía; el lector principal son mis colegas y el secundario soy yo dentro de 10 años. jj me permite manejar eso con mucha menos fricción
  • Está bien pedirle ayuda a un LLM; yo también lo hice hasta aprender los comandos básicos que necesitaba
    Leí varias guías de principio a fin para afianzar las bases de la terminología y las funciones, y después de usarlo de forma constante durante unos días en proyectos personales, ya me manejaba bastante bien con las tareas básicas, y también cambió mi forma de ver el VCS
    Cuando hago refactoring o desarrollo una función grande, primero implemento todo hasta el objetivo final y luego lo divido en cambios pequeños que sean fáciles de revisar y donde la justificación de cada uno sea clara, como “corregir todas las advertencias de eslint”, “refactor para exponer la función”, “cambiar el sitio de llamada A a la nueva función” y “agregar la nueva funcionalidad”. jj split es perfecto para esto, y solo esa función ya basta para justificar usar jj
    En cambio, git stash tiene muchas trampas de usabilidad peligrosas: es difícil manejar varios stashes y, si hay conflictos, existe el riesgo de perder el código que guardaste. Incorporar feedback de un PR en un commit bajo y luego hacer rebase de los commits o PR de arriba, especialmente en PR apilados, es casi una pesadilla porque no hay indicador de progreso y es difícil retomar o volver a apilar si se interrumpe a la mitad. Por eso todavía uso Graphite para manejar PR apilados
  • El beneficio más grande que obtuve de jj es cómo maneja el rebase
    Un estudiante de posgrado en química orgánica desarrolló durante 4 años una rama para trabajar en un paper sin hacer merge ni rebase, así que estaba miles de commits detrás de main cuando tuvo que fusionarla antes de su defensa. Como había conflictos en casi todos los commits, con Git eso tomaba entre 1 y 2 semanas, y si al tercer día entraba un bug urgente, había que abortar el rebase, corregir el bug y luego empezar desde cero; cuando terminabas 3 semanas después, todavía tenías que volver a hacer rebase para ajustarte al main más reciente
    En jj, los conflictos de merge son objetos de primera clase, así que puedes resolverlos cuando tengas tiempo, y aunque a mitad del proceso te muevas a un commit nuevo para corregir un bug urgente, no pierdes el progreso. Un rebase que en Git tomaría una semana pude terminarlo en un día, y una vez encontré 200 commits seguidos que, incluso fusionados, no producían ningún cambio, así que pude desechar en menos de un minuto un trabajo que de otro modo me habría tomado dos días resolviendo decenas de miles de líneas en conflicto. Incluso durante un rebase puedes actualizar main y mover la rama en la que estás trabajando encima del main más reciente

• Incluso para alguien como yo, demasiado acostumbrado a Git y que solo busca un comando de vez en cuando, este artículo fue la primera introducción a Jujutsu que me pareció interesante
  Los artículos anteriores normalmente empezaban con “puedes escapar de la terrible interfaz de línea de comandos de Git”, y aunque entiendo lo peculiar que es Git y las dificultades que tienen otras personas, esa forma de presentarlo hacía que viera Jujutsu como algo ajeno a mí, como una novela romántica o un beef vindaloo

  • La razón por la que es difícil explicar el placer de usar jj es que muchas propiedades implícitas que yo daba por sentadas en cualquier VCS en realidad no lo están, y porque las operaciones atómicas son mucho más simples
    Como es difícil crear una buena frase promocional, al final toda la explicación termina reducida a “no es Git”, y yo mismo tampoco soy muy bueno explicándolo
  • En Git, usando la GUI Sublime Merge y algunos comandos personalizados, se pueden resolver casi todos los problemas de los que se habla aquí
    A diferencia de otras GUIs de Git, sigue los comandos reales de Git lo más fielmente posible, solo reemplaza la sintaxis enredada por menús y botones, y tampoco oculta el comando correspondiente a cada acción: lo deja registrado en la barra de estado. Si saliera Sublime JJ, me cambiaría de inmediato
  • La frase que hizo que quisiera probar jj fue esta: Git siempre en estado de rebase interactivo