jj

@meow2149 我记得之前不是有很多用rust重写git的案例吗？还有很多重新定义commit的，比如jj。这些库大厂都瞧不上吗？ jj-vcs/jj

AnthropicはなぜGitをやめたのか｜バージョン管理の歴史から読み解く【Scion】 Claudeを作るAnthropicは、社内の巨大なコード置き場でGitをやめ、自前の「Scion」に切り替えました。 なぜGitでは足りなかったのか。バージョン管理の歴史をたどりながら、Gitの「前提」と、AI時代にGitは入れ替わるのかを考えます。 ※Anthropic の公式動画ではありません。 ■ チャプター 0:00 Anthropicが、Gitをやめた 0:47 「前の版に戻したい」の歴史 3:36 Gitの前提は「全部を、手元に」 6:32 よく言われるが、実は（巨大企業とGit） 8:05 Gitの前提が合わなくなった 11:45 Gitはもう古いのか？ 14:41 私の考え 15:26 これから ■ 数字について ・Gitの履歴を丸ごと取る／必要な分だけ取る、20個の同時 push の回数は、自分の環境で測った参考値です ・「約300倍」「3日かからない」は、記事の数字から計算したざっくりの比較です ・Anthropic の数字は、同社の報告からです ■ 資料・参考 ・Anthropic, Redesigning source control at Anthropic（原文）：anthropic.com ・Simon Willison による紹介：simonwillison.net ・Google の単一リポジトリ（CACM 2016）：cacm.acm.org ・Meta Sapling：engineering.fb.com ・Jujutsu（README）：jj-vcs/jj ・Pijul：pijul.org ・SCCS：en.wikipedia.org ・RCS：en.wikipedia.org ・CVS：w3.pppl.gov ・Subversion：svnbook.red-bean.com ・BitKeeper の終了（LWN, 2005）：lwn.net ・git の名前（README）：git/git ・Git：en.wikipedia.org ・GitHub：en.wikipedia.org ・リーナスの Google Tech Talk（書き起こし）：singjupost.com ・partial clone：git-scm.com ※ナレーションはAI音声です。 内容に間違いがあれば、コメントで教えてください。 チャンネル登録もよろしくお願いします。 #Git #AI #バージョン管理

jj (Jujutsu) is a Git-compatible VCS where your working copy is always a commit, and `jj undo` reverses the last operation, rebases included. It runs on top of an existing git repo, so you can try it without telling anyone. jj-vcs/jj

¿Jujutsu funciona con GitHub? ¿De dónde viene el nombre? 7 preguntas y respuestas --- title: ¿Jujutsu funciona con GitHub? ¿De dónde viene el nombre? 7 preguntas y respuestas published: true date: 2026-10-20 00:00:00 UTC tags: jujutsu,git,github,spanish cover_image: dev-to-uploads.s3.us-east-2.amazonaws.com canonical_url: juju-chu.com --- 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^{<a href="#user-content-fn-jj-plug" id="user-content-fnref-jj-plug" data-footnote-ref aria-describedby="footnote-label">1</a>}. 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^{<a href="#user-content-fn-submod-sup" id="user-content-fnref-submod-sup" data-footnote-ref aria-describedby="footnote-label">2</a>}. 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^{<a href="#user-content-fn-gh-lg-file" id="user-content-fnref-gh-lg-file" data-footnote-ref aria-describedby="footnote-label">3</a>}. Se usa mucho en áreas como el desarrollo de videojuegos, y tampoco está soportado. Se está trabajando en ello, con varios PRs ya abiertos^{<a href="#user-content-fn-sup-lfs" id="user-content-fnref-sup-lfs" data-footnote-ref aria-describedby="footnote-label">4</a>}, 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^{<a href="#user-content-fn-no-verify" id="user-content-fnref-no-verify" data-footnote-ref aria-describedby="footnote-label">5</a>}. 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^{<a href="#user-content-fn-other-immutable" id="user-content-fnref-other-immutable" data-footnote-ref aria-describedby="footnote-label">6</a>}: [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^{<a href="#user-content-fn-git-cmd-table" id="user-content-fnref-git-cmd-table" data-footnote-ref aria-describedby="footnote-label">7</a>}. 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». !Una cita de Yoda 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](#q2-qu%C3%A9-cosas-puede-hacer-git-que-jujutsu-todav%C3%ADa-no) 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^{<a href="#user-content-fn-contrib" id="user-content-fnref-contrib" data-footnote-ref aria-describedby="footnote-label">8</a>}. ¿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^{<a href="#user-content-fn-jjcon-keynote" id="user-content-fnref-jjcon-keynote" data-footnote-ref aria-describedby="footnote-label">9</a>}. 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^{<a href="#user-content-fn-other-tool" id="user-content-fnref-other-tool" data-footnote-ref aria-describedby="footnote-label">10</a>}. 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^{<a href="#user-content-fn-disc3021" id="user-content-fnref-disc3021" data-footnote-ref aria-describedby="footnote-label">11</a>}, 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^{<a href="#user-content-fn-disc2520" id="user-content-fnref-disc2520" data-footnote-ref aria-describedby="footnote-label">12</a>}, 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^{<a href="#user-content-fn-pr3042" id="user-content-fnref-pr3042" data-footnote-ref aria-describedby="footnote-label">13</a>}. 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 de Jujutsu 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_. {% embed 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. <section data-footnotes><h2 id="footnote-label">Footnotes</h2> <ol> <li id="user-content-fn-jj-plug"> <p>Además de Git, Jujutsu también puede usar como backend <a href="en.wikipedia.org)">Piper</a>, 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. <a href="#user-content-fnref-jj-plug" data-footnote-backref="" aria-label="Back to reference 1">↩</a></p> </li> <li id="user-content-fn-submod-sup"> <p><a href="docs.jj-vcs.dev">“Submodule support - Development roadmap - Jujutsu docs”</a> <a href="jj#494">“Add support for Git submodules · Issue #494 · jj-vcs/jj”</a> <a href="#user-content-fnref-submod-sup" data-footnote-backref="" aria-label="Back to reference 2">↩</a></p> </li> <li id="user-content-fn-gh-lg-file"> <p><a href="docs.github.com">“Acerca de los archivos grandes en GitHub - Documentación de GitHub”</a> <a href="#user-content-fnref-gh-lg-file" data-footnote-backref="" aria-label="Back to reference 3">↩</a></p> </li> <li id="user-content-fn-sup-lfs"> <p><a href="jj#80">“Add support for Git LFS · Issue #80 · jj-vcs/jj”</a> <a href="#user-content-fnref-sup-lfs" data-footnote-backref="" aria-label="Back to reference 4">↩</a></p> </li> <li id="user-content-fn-no-verify"> <p><a href="github.com/jj-vcs/jj/blob/main/lib/src/git_subpro…">“jj/lib/src/git_subprocess.rs at main · jj-vcs/jj”</a> <a href="#user-content-fnref-no-verify" data-footnote-backref="" aria-label="Back to reference 5">↩</a></p> </li> <li id="user-content-fn-other-immutable"> <p>La documentación oficial también muestra otras configuraciones, como una que impide reescribir commits creados por otras personas. <a href="jj-vcs.dev">“Set of immutable commits - Configuration - Jujutsu docs”</a> <a href="#user-content-fnref-other-immutable" data-footnote-backref="" aria-label="Back to reference 6">↩</a></p> </li> <li id="user-content-fn-git-cmd-table"> <p>La documentación oficial también tiene una. <a href="docs.jj-vcs.dev">“Git command table - Jujutsu docs”</a> <a href="#user-content-fnref-git-cmd-table" data-footnote-backref="" aria-label="Back to reference 7">↩</a></p> </li> <li id="user-content-fn-contrib"> <p><a href="docs.jj-vcs.dev">“Paying employers and their contributing employees - Jujutsu docs”</a> <a href="#user-content-fnref-contrib" data-footnote-backref="" aria-label="Back to reference 8">↩</a></p> </li> <li id="user-content-fn-jjcon-keynote"> <p><a href="youtube.com">“JJ Con • Keynote - YouTube”</a> <a href="#user-content-fnref-jjcon-keynote" data-footnote-backref="" aria-label="Back to reference 9">↩</a></p> </li> <li id="user-content-fn-other-tool"> <p><a href="docs.github.com">“Usa otras herramientas con pull requests apiladas - Documentación de GitHub”</a> <a href="#user-content-fnref-other-tool" data-footnote-backref="" aria-label="Back to reference 10">↩</a></p> </li> <li id="user-content-fn-disc3021"> <p><a href="jj#3021">“Question: What’s ‘jujutsu’ from? · jj-vcs/jj · Discussion #3021”</a> <a href="#user-content-fnref-disc3021" data-footnote-backref="" aria-label="Back to reference 11">↩</a></p> </li> <li id="user-content-fn-disc2520"> <p><a href="jj#2520">“Proposal: Rename Jujutsu to Jojo · jj-vcs/jj · Discussion #2520”</a> <a href="#user-content-fnref-disc2520" data-footnote-backref="" aria-label="Back to reference 12">↩</a></p> </li> <li id="user-content-fn-pr3042"> <p><a href="jj#3042">“meta: cement “Jujutsu” (呪術) as the project name by thoughtpolice · Pull Request #3042 · jj-vcs/jj”</a> <a href="#user-content-fnref-pr3042" data-footnote-backref="" aria-label="Back to reference 13">↩</a></p> </li> </ol> </section>

O Jujutsu funciona com o GitHub? De onde vem o nome? 7 perguntas e respostas --- title: O Jujutsu funciona com o GitHub? De onde vem o nome? 7 perguntas e respostas published: true date: 2026-10-20 00:00:00 UTC tags: jujutsu,git,braziliandevs,ptbr cover_image: dev-to-uploads.s3.us-east-2.amazonaws.com canonical_url: juju-chu.com --- Q1. Dá para usar o Jujutsu nos meus repositórios Git atuais? Dá, sim. O Jujutsu é altamente compatível com o Git, e basta rodar jj git init dentro de um repositório Git existente para começar a usar o Jujutsu nele. Você não perde nada ao experimentar e não precisa abrir mão do Git. A camada de armazenamento do Jujutsu é plugável, e o Git é o backend padrão^{<a href="#user-content-fn-jj-plug" id="user-content-fnref-jj-plug" data-footnote-ref aria-describedby="footnote-label">1</a>}. O backend do Git guarda os commits como objetos Git comuns, então o histórico que você cria com o Jujutsu também pode ser acessado pelas ferramentas do Git. Um repositório em que o Jujutsu e o Git convivem lado a lado é chamado de colocated. Antes, para ter um, você precisava passar a opção --colocate para o jj git init, ou para o jj git clone ao copiar um repositório remoto. Desde a v0.34.0, lançada em outubro de 2025, colocated é o padrão. Você ainda vai ver --colocate em artigos mais antigos, mas hoje pode ignorar essa opção sem medo. Num repositório colocated, um diretório .jj/ fica ao lado do .git/ na raiz. O .gitignore dentro do .jj/ contém /*, então adicionar o Jujutsu não mexe no .gitignore da raiz. Como mencionei acima, o histórico de commits do Git continua sendo atualizado enquanto você usa o Jujutsu, e você pode fazer push para o GitHub ou qualquer outro remoto normalmente. Commits assinados também são suportados, então ele funciona em repositórios que os exigem. Ou seja, se quiser, você pode ser a única pessoa de um time de Git que usa o Jujutsu. Os comandos do Git também continuam funcionando num repositório colocated. E, se você decidir que o Jujutsu não é para você, dá para voltar ao Git apagando o diretório .jj/. O Jujutsu deixa a sua configuração do Git do jeito que está, então testá-lo não traz praticamente nenhum custo nem risco. Q2. O que o Git faz que o Jujutsu não faz? Apesar de toda a compatibilidade com o Git, o Jujutsu ainda não suporta alguns recursos do Git, nem mesmo na v0.46.0, a versão mais recente em outubro de 2026. Três deles são os que têm mais chance de causar problemas em projetos reais: - Submódulos - LFS (Large File Storage) - Hooks do Git ou um equivalente direto O mais sério deles provavelmente é a falta de suporte a submódulos. Os submódulos do Git permitem embutir outro repositório Git independente como um subdiretório, normalmente para compartilhar código entre projetos. Não ter suporte não significa que o conteúdo dos seus submódulos se perde. O verdadeiro problema é que o conteúdo deles não se atualiza automaticamente quando você se move pelo histórico. Com jj edit, dá para pular para qualquer ponto do histórico como numa máquina do tempo e ver ou editar os arquivos ali, mas os diretórios dos submódulos ficam como estavam. Você precisa rodar git submodule update --recursive na mão toda vez. O Jujutsu também ignora as alterações que você faz dentro de um submódulo, então, para registrá-las no histórico, você precisa rodar git add e git commit por conta própria. Ainda dá para trabalhar num repositório com submódulos, mas você precisa entender as limitações e cuidar na mão das operações que não são suportadas. Do lado do desenvolvimento, os submódulos não combinam bem com o modelo de dados do Jujutsu, e suportá-los exigiria grandes mudanças de design, o que é um dos principais motivos do atraso. Isso está no roadmap, mas boa parte da documentação de design ainda não está pronta, e não há previsão de implementação^{<a href="#user-content-fn-submod-sup" id="user-content-fnref-submod-sup" data-footnote-ref aria-describedby="footnote-label">2</a>}. Hoje em dia, times que precisam compartilhar código costumam escolher um monorepo ou pacotes privados em algo como o GitHub Packages em vez de submódulos. Se a decisão for sua, vale a pena considerar essas opções em projetos novos. O Git LFS é uma extensão do Git para vídeo, áudio, binários grandes e outros arquivos pesados. Ele guarda os dados grandes fora do repositório e mantém no Git só ponteiros para eles. No GitHub, o Git LFS é hoje a única forma de gerenciar num repositório arquivos com mais de 100 MB^{<a href="#user-content-fn-gh-lg-file" id="user-content-fnref-gh-lg-file" data-footnote-ref aria-describedby="footnote-label">3</a>}. Ele é muito usado em áreas como desenvolvimento de jogos, e também não é suportado. O trabalho está em andamento, com vários PRs já abertos^{<a href="#user-content-fn-sup-lfs" id="user-content-fnref-sup-lfs" data-footnote-ref aria-describedby="footnote-label">4</a>}, mas ainda há questões de design em aberto, incluindo algumas que afetam outros recursos. Ainda não há uma previsão clara de lançamento. Por fim, os hooks do Git. Os hooks executam scripts próprios em resposta a ações específicas do Git, e muito mais times dependem deles do que dos outros dois recursos. Os usos típicos são rodar formatadores e linters antes de um commit, ou testes e auditorias de segurança antes de um push. Husky com lint-staged, e Lefthook, são as ferramentas populares para isso. Os comandos do Jujutsu nunca disparam hooks do Git. O jj git push, por exemplo, chama o git push internamente, mas passa --no-verify para pular os hooks de propósito^{<a href="#user-content-fn-no-verify" id="user-content-fnref-no-verify" data-footnote-ref aria-describedby="footnote-label">5</a>}. Oficialmente, não há como disparar os hooks do Git no momento que você quiser, nem um mecanismo de hooks próprio do Jujutsu. O motivo é que os hooks não combinam com o design central e o modelo de dados do Jujutsu. Dois fatores se destacam: - O Jujutsu faz commit das suas alterações automaticamente enquanto você trabalha, então não existe uma etapa explícita de commit antes da qual os hooks possam rodar. - O Jujutsu reescreve código sem passar pelo seu diretório de trabalho, por exemplo, quando você faz squash ou quando a edição de um commit antigo provoca um rebase automático dos seus descendentes. Passar nos testes no commit original não garante que eles continuem passando lá na frente. Embora não cubram tudo o que os hooks do Git fazem, o Jujutsu oferece algumas ferramentas oficiais que se encaixam no modelo dele. Com o jj fix, você registra formatadores na sua configuração e, ao rodá-lo, ele percorre o seu histórico mutável de trás para frente e formata os arquivos alterados em cada commit. O jj run executa um comando externo sobre um único commit ou um intervalo de commits. Dá para usá-lo para rodar builds ou testes ao longo do histórico e, como ele incorpora aos commits correspondentes as alterações que o comando faz nos arquivos, também serve para linters com correção automática ou outras ferramentas que corrigem código. E se o seu time tiver uma configuração de hooks elaborada, montada em torno do Git, e você quiser ser a única pessoa usando o Jujutsu? Há várias abordagens dependendo da situação, e o assunto renderia fácil um ou dois artigos, então vou deixá-lo de fora aqui. Se tiver curiosidade, meu livro _Juju-chu! — Comece seu fluxo de trabalho Jujutsu × IA com jj new_ trata disso na seção “4-3. Táticas alternativas para os Git hooks”. Q3. O Jujutsu funciona com o GitHub? Funciona. Como o Jujutsu usa o Git como backend, ele funciona sem problemas esteja o seu remoto no GitHub, no GitLab ou no Bitbucket. O porém é que o Jujutsu compartilha o trabalho por meio de um conceito diferente, chamado bookmark, em vez de um branch, e se acostumar com isso pode ser o verdadeiro obstáculo. O Jujutsu não tem nada que corresponda aos branches com nome do Git. Normalmente você trabalha em branches anônimos e, na hora de compartilhar, coloca um bookmark no commit que quiser. Quando você faz push de um commit com bookmark para um remoto, o Git o enxerga como um branch. O confuso é que o GitHub trata isso como um branch, embora seja um conceito diferente, com outro comportamento. Quem está começando costuma estranhar estes pontos: - Um bookmark não se move automaticamente para o seu commit mais recente; é você quem precisa movê-lo. - Um mecanismo chamado tracking mantém sincronizada a posição de um bookmark (e também sua exclusão) entre o repositório local e o remoto. - O tracking é praticamente indispensável, então os nomes dos bookmarks locais e remotos precisam ser iguais. - Também dá para criar um bookmark na hora do push com a opção -c/--change ou --named, mesmo que ainda não exista nenhum. Por que o Jujutsu tem bookmarks em vez de branches, e o que você ganha ao compartilhar o trabalho com eles, eu explico em detalhes no meu post anterior, “O Jujutsu não tem o passo de ‘criar um branch’, e foi isso que finalmente me fez entender os branches do Git”. Uma diferença de comportamento em relação ao Git depois do push: se você reescrever commits que já enviou e fizer push de novo, isso vira automaticamente um force push. O Jujutsu sempre faz push de um jeito parecido com --force-with-lease, e no nível local você está protegido contra reescritas acidentais dependendo de o commit ser mutável ou imutável. Por padrão, porém, os commits já enviados fora do trunk continuam mutáveis, então você pode reescrevê-los, e fazer push do resultado acaba virando um force push. Isso pode bater de frente com a política de times que desenvolvem em feature branches compartilhados. Nesse caso, mude quais commits contam como imutáveis com uma configuração como esta^{<a href="#user-content-fn-other-immutable" id="user-content-fnref-other-immutable" data-footnote-ref aria-describedby="footnote-label">6</a>}: [revset-aliases] 'immutable_heads()' = 'builtin_immutable_heads() | remote_bookmarks("feature/*", "origin")' Fora isso, abrir, aprovar e fazer merge de PRs, além de CI/CD com GitHub Actions e afins, funcionam quase exatamente do mesmo jeito com o Jujutsu. Praticamente a única diferença é que, quando você apaga o branch remoto no GitHub depois do merge de um PR, o próximo jj git fetch apaga também o bookmark local vinculado. Q4. No fim das contas, o que o Jujutsu oferece a mais que o Git? Comparado com o Git, é isto que você ganha ao mudar para o Jujutsu: - Não existe índice (staging area). Não há nenhuma etapa como git add para rodar. - Os commits acontecem automaticamente. Sempre que você roda um comando jj e há arquivos alterados desde o último commit, o Jujutsu tira um novo snapshot e atualiza o commit. - Graças a essas duas coisas, a cópia de trabalho (o que o Git chama de working tree) é tratada como um commit em si. Você pode andar pelo histórico como numa máquina do tempo sem se preocupar com alterações não commitadas nem em manter o índice consistente, como no Git. - Quando você reescreve qualquer commit, os descendentes dele passam por rebase automaticamente. - Por mais conflitos que um rebase encontre, ele termina normalmente, sem jogar você num modo interativo, e deixa os conflitos no lugar. Como os estados com conflito ficam registrados no histórico , refazer uma resolução ou entregá-la a uma ferramenta é fácil. - Exceto pelas operações que afetam um repositório remoto, o jj undo pode desfazer quase qualquer alteração. - Todo comando jj que altera o repositório, e todo snapshot automático, vai para o registro de operações (operation log). Depois, você pode restaurar o repositório a um estado anterior ou reverter uma operação específica. - Não é preciso criar um branch e dar nome a ele só para experimentar. Comece com jj new e, se não gostar do rumo, descarte com jj abandon e tente de novo. - Os comandos são diretos e fáceis de lembrar. Fazer squash, por exemplo, é jj squash --from A --into B. As opções que indicam sobre o que operar e para onde levar, como -f/--from, -t/--into, -o/--onto, -A/--insert-after e -B/--insert-before, funcionam de forma consistente entre os comandos relacionados. Q5. A curva de aprendizado é íngreme? Você não precisa de muitos comandos para começar. Só com estes, já deve dar conta de todo o fluxo de trabalho básico: | O que você quer fazer | Comando | | --- | --- | | Ver o status | jj st | | Ver o log | jj log | | Ver o diff | jj diff | | Atualizar a mensagem do commit | jj desc -m '...' | | Começar o próximo trabalho | jj new | | Desfazer a última operação | jj undo | | Definir um bookmark | jj bookmark set <name> | | Buscar do remoto | jj git fetch | | Fazer push para o remoto | jj git push -b <bookmark> | Só com isso você já aproveita os commits automáticos e o undo e, se achar isso valioso, já superou o primeiro obstáculo. O problema vem depois. Quanto mais experiência a pessoa tem com o Git, maior a chance de ela usar o Jujutsu com o modelo mental do Git intacto, consultando uma tabela de equivalência de comandos^{<a href="#user-content-fn-git-cmd-table" id="user-content-fnref-git-cmd-table" data-footnote-ref aria-describedby="footnote-label">7</a>}. Desse jeito, você só está traduzindo operações do Git uma a uma, perde boa parte do que o Jujutsu tem de útil e ainda ganha o trabalho de traduzir comandos. O Jujutsu foi projetado para resolver o que torna o Git difícil de usar. Ele continua compatível com o Git, mas repensa o modelo mental do zero. Para tirar o máximo proveito dele, você precisa seguir o conselho do Yoda: “Você deve desaprender o que aprendeu.” !Uma citação do Yoda É por isso que a etapa seguinte é a difícil. A dificuldade não vem de o Jujutsu ser complicado. Vem de ter que repensar hábitos de controle de versão que você construiu ao longo de anos com o Git, e largar conceitos que você sempre deu como certos. De vez em quando, vejo gente que nunca percebe isso, continua tocando o fluxo de trabalho do Git em cima do Jujutsu, não sente nenhum benefício e volta para o Git. Pela minha experiência, focar nestas três coisas é o caminho mais rápido para desenvolver um modelo mental do Jujutsu: 1. Entenda o que é um change, a unidade usual de histórico do Jujutsu - Pense num change como um contêiner com um nome e um ID que nunca muda, e nos commits (também chamados de revisões) como versões sucessivas de um documento guardadas dentro dele. Não é tecnicamente preciso, mas é uma imagem fácil para quem está começando 2. Abandone a ideia de que você só faz commit quando o trabalho está pronto - No Jujutsu, toda vez que você muda o código ou a descrição (grosso modo, a mensagem do commit), é como se um git commit --amend --no-edit rodasse na hora, automaticamente. Os changes estão inacabados por padrão e, quando você chega a um bom ponto de parada, simplesmente passa para outro change - Não use o jj commit, que roda jj desc e depois jj new de uma vez só e existe para dar suporte a fluxos de trabalho no estilo do Git 3. Acostume-se a não ter um “branch atual” enquanto trabalha - Fique num único fluxo: trabalhe num branch anônimo e coloque um bookmark só quando quiser compartilhar - Crie o hábito de ver onde você está no grafo que o jj log desenha, em vez de se guiar pelo nome do branch Depois que você larga o fluxo de trabalho do Git e continua trabalhando do jeito do Jujutsu, a lógica por trás do design dele começa a fazer sentido. A essa altura, usar o Jujutsu vai se tornar algo completamente natural, e você não vai mais querer trabalhar sem ele. Q6. O Jujutsu ainda não chegou à 1.0. É seguro usar no trabalho? A resposta curta: se os problemas da [Q2](#q2-o-que-o-git-faz-que-o-jujutsu-n%C3%A3o-faz) não afetam você, na prática quase nada impede você de usar. A CLI e a configuração vão continuar mudando, porém, então a verdadeira questão na hora de decidir pela adoção é se você consegue conviver com isso. O README no repositório oficial do GitHub diz: > 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. > (O Jujutsu é um sistema de controle de versão experimental. Embora a compatibilidade com o Git seja estável e a maioria dos desenvolvedores o use diariamente para tudo de que precisa, ainda pode haver recursos em desenvolvimento, uma UX com espaço para melhorar e lacunas nos fluxos de trabalho que o tornem inviável para o seu caso específico.) Ele também diz que os fluxos de trabalho podem mudar e que pode haver mudanças incompatíveis no formato dos dados em disco antes da 1.0, acrescentando que o projeto vai tentar oferecer atualizações transparentes quando o formato mudar. Isso pode soar um pouco preocupante, mas não tem havido grandes mudanças incompatíveis ultimamente. A maioria foi remoção de configurações e opções de comando obsoletas, ou mudança nos requisitos de sistema. A v0.38.0, lançada em fevereiro de 2026, mudou o lugar onde ficam os arquivos de configuração de cada repositório, mas foi por motivos de segurança, um passo necessário para proteger os usuários de ataques maliciosos. Martin von Zweigbergk, ex-engenheiro do Google, começou o Jujutsu como projeto paralelo no fim de 2019, e a primeira versão no GitHub, a v0.3.0, saiu em março de 2022. Isso foi há quatro anos e meio. Desde a v0.9.0, em setembro de 2023, sai uma versão nova quase todo mês. Pode não ser 1.0 ainda, mas tem um histórico sólido. Em outubro de 2026, o repositório oficial no GitHub tem cerca de 32 mil estrelas. O projeto tem nove maintainers, e cada release dá crédito a cerca de 30 contribuidores. Engenheiros de várias empresas, entre elas o Google, contribuem de forma contínua. A documentação oficial lista as empresas que financiam o desenvolvimento do Jujutsu e os funcionários que participam dele^{<a href="#user-content-fn-contrib" id="user-content-fnref-contrib" data-footnote-ref aria-describedby="footnote-label">8</a>}. E a adoção no mundo real? Comentei que o criador veio do Google. Segundo ele, cerca de 900 pessoas dentro do Google já usavam o Jujutsu em setembro de 2025^{<a href="#user-content-fn-jjcon-keynote" id="user-content-fnref-jjcon-keynote" data-footnote-ref aria-describedby="footnote-label">9</a>}. Em julho de 2026, ele se tornou CTO da ERSC, uma empresa que oferece uma plataforma de hospedagem cujo armazenamento foi projetado em torno do modelo do Jujutsu e que planeja suportar no futuro um protocolo nativo para clientes do Jujutsu. O fato de haver empresas que baseiam seus negócios no Jujutsu é um bom sinal da confiabilidade dele. Além disso, os stacked pull requests do GitHub, que dividem um PR numa cadeia de PRs pequenos e dependentes, ficaram disponíveis para todos há pouco tempo, e a documentação deles inclui uma página que mostra um fluxo de trabalho com o Jujutsu^{<a href="#user-content-fn-other-tool" id="user-content-fnref-other-tool" data-footnote-ref aria-describedby="footnote-label">10</a>}. É justo ler isso como sinal de que o GitHub vê o Jujutsu como um cliente compatível, com usuários demais para ser ignorado, e ao qual vale a pena dar suporte. Não acho que a falta de uma 1.0 se deva a dúvidas sobre a qualidade ou a confiabilidade dele. Na verdade, suspeito que os desenvolvedores queiram manter a liberdade de mudar o design enquanto ele continua evoluindo. Muitos desenvolvedores já o usam todo dia, e há empresas que continuam apoiando o desenvolvimento. No mínimo, não ter chegado à 1.0 não é, por si só, motivo para evitar usá-lo no trabalho. Q7. Por que o nome “Jujutsu”? Muita gente acha que o nome vem do anime _Jujutsu Kaisen_. No Japão, ele é até zoado nas redes sociais por soar meio exagerado, com cara de nome de anime. Mas o Jujutsu não tem nada a ver com _Jujutsu Kaisen_. Então, de onde vem o nome? O README oficial no GitHub sugere que o nome do comando, jj, veio primeiro: > 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”. Com o indicador direito apoiado na tecla J, na fileira central do teclado, bastam dois toques, então é mesmo fácil de digitar. O README dá a entender que Jujutsu foi escolhido desde o início como um nome que combinava com jj, mas, na verdade, o projeto teve outro nome no começo. No crates.io, o registro oficial de pacotes do Rust, existe um VCS chamado Jujube. O autor é Martin von Zweigbergk, e ele tem duas versões, 0.1.0 e 0.1.1, lançadas em janeiro de 2021. Isso mesmo: é o antecessor do Jujutsu. Veja o que a página dele diz sobre o nome: > 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”. Em inglês, _jujube_ é o nome de uma fruta: a jujuba (também conhecida como tâmara-chinesa). Mais uma vez, o nome foi escolhido simplesmente porque combinava com jj. Apenas quatro meses depois, o nome mudou. A mensagem de commit dessa troca de nome continua lá: > 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 Pelo jeito, o autor não tinha nenhum apego especial a Jujube e trocou para Jujutsu por ser um nome mais conhecido e mais próximo da maioria das pessoas. Quando mais tarde alguém perguntou de onde vinha o nome^{<a href="#user-content-fn-disc3021" id="user-content-fnref-disc3021" data-footnote-ref aria-describedby="footnote-label">11</a>}, ele apontou o artigo da Wikipédia sobre o jujutsu, então o nome se refere à arte marcial japonesa. Em inglês, a arte tradicional japonesa costuma ser grafada “jujutsu”, enquanto “jiu-jitsu” é a grafia que a maioria conhece por causa do jiu-jitsu brasileiro. A Wikipédia em inglês tem um artigo separado sobre o jiu-jitsu brasileiro, mas quem busca “jiu-jitsu” ou “jiujitsu” é redirecionado para o artigo sobre o jujutsu. Sem esse redirecionamento, talvez o projeto hoje se chamasse Jiu-jitsu. Então está decidido que o nome se refere à arte marcial? Não exatamente. O autor diz que nunca deu nenhum significado especial ao nome. Quando alguém propôs renomear o Jujutsu para Jojo^{<a href="#user-content-fn-disc2520" id="user-content-fnref-disc2520" data-footnote-ref aria-describedby="footnote-label">12</a>}, ele também não pareceu muito apegado a Jujutsu e sugeriu que fizessem uma votação. Também houve uma proposta de adotar oficialmente outro significado e outra pronúncia^{<a href="#user-content-fn-pr3042" id="user-content-fnref-pr3042" data-footnote-ref aria-describedby="footnote-label">13</a>}. Em japonês, “jujutsu” pode corresponder a duas palavras diferentes: 柔術 (jūjutsu, a arte marcial) e 呪術 (jujutsu, feitiçaria, a palavra de _Jujutsu Kaisen_; maldição é outra palavra). A proposta era tornar 呪術 o significado oficial, e o próprio autor gostou da ideia no começo. No fim, porém, a definição de um significado ou de uma pronúncia oficial ficou de lado. O logo oficial, em uso desde 2025, mostra a mesma postura de não dar ao nome nenhum significado em particular. !O logo do Jujutsu Dois pássaros azuis estão de costas um para o outro. São gaios (aves da família dos corvídeos chamadas _jays_ em inglês). A palavra _jay_ tem a mesma pronúncia da letra J em inglês: dois gaios formam “jay jay”, ou seja, jj. Não só o nome: o logo também é um trocadilho com jj. Se a arte marcial fosse o significado oficial, o logo com certeza mostraria algo ligado a ela, mas não é o caso. No fim das contas, tudo começou com jj, um nome de comando curto e fácil de digitar. O projeto foi batizado de Jujutsu por causa da arte marcial e, mesmo assim, oficialmente não significa nem 柔術 nem 呪術. Jujutsu é só Jujutsu, e essa provavelmente é a verdadeira resposta para a origem do nome. Ainda tem dúvidas? São sete dúvidas comuns que quem usa Git costuma ter quando pensa em dar uma chance ao Jujutsu. Algumas destas respostas foram reelaboradas a partir das perguntas frequentes do capítulo 5, “Guia de solução de problemas do Jujutsu”, do meu livro _Juju-chu! — Comece seu fluxo de trabalho Jujutsu × IA com jj new_. {% embed juju-chu.com %} O livro responde a muitas outras perguntas que costumam surgir para quem está chegando ao Jujutsu, além de mostrar como lidar com os problemas que você provavelmente vai encontrar quando começar. Se você está começando com o Jujutsu, ele deve economizar bastante tempo, então dê uma olhada. <section data-footnotes><h2 id="footnote-label">Footnotes</h2> <ol> <li id="user-content-fn-jj-plug"> <p>Além do Git, o Jujutsu também pode usar como backend o <a href="en.wikipedia.org)">Piper</a>, o sistema de controle de versão usado dentro do Google, mas essa parte não é pública. Um backend nativo do Jujutsu parece estar na lista de desejos, mas nenhum plano concreto foi anunciado. <a href="#user-content-fnref-jj-plug" data-footnote-backref="" aria-label="Back to reference 1">↩</a></p> </li> <li id="user-content-fn-submod-sup"> <p><a href="docs.jj-vcs.dev">“Submodule support - Development roadmap - Jujutsu docs”</a> <a href="jj#494">“Add support for Git submodules · Issue #494 · jj-vcs/jj”</a> <a href="#user-content-fnref-submod-sup" data-footnote-backref="" aria-label="Back to reference 2">↩</a></p> </li> <li id="user-content-fn-gh-lg-file"> <p><a href="docs.github.com">“Sobre arquivos grandes no GitHub - Documentos do GitHub”</a> <a href="#user-content-fnref-gh-lg-file" data-footnote-backref="" aria-label="Back to reference 3">↩</a></p> </li> <li id="user-content-fn-sup-lfs"> <p><a href="jj#80">“Add support for Git LFS · Issue #80 · jj-vcs/jj”</a> <a href="#user-content-fnref-sup-lfs" data-footnote-backref="" aria-label="Back to reference 4">↩</a></p> </li> <li id="user-content-fn-no-verify"> <p><a href="github.com/jj-vcs/jj/blob/main/lib/src/git_subpro…">“jj/lib/src/git_subprocess.rs at main · jj-vcs/jj”</a> <a href="#user-content-fnref-no-verify" data-footnote-backref="" aria-label="Back to reference 5">↩</a></p> </li> <li id="user-content-fn-other-immutable"> <p>A documentação oficial também mostra outras configurações, como uma que impede reescrever commits criados por outras pessoas. <a href="jj-vcs.dev">“Set of immutable commits - Configuration - Jujutsu docs”</a> <a href="#user-content-fnref-other-immutable" data-footnote-backref="" aria-label="Back to reference 6">↩</a></p> </li> <li id="user-content-fn-git-cmd-table"> <p>A documentação oficial também tem uma. <a href="docs.jj-vcs.dev">“Git command table - Jujutsu docs”</a> <a href="#user-content-fnref-git-cmd-table" data-footnote-backref="" aria-label="Back to reference 7">↩</a></p> </li> <li id="user-content-fn-contrib"> <p><a href="docs.jj-vcs.dev">“Paying employers and their contributing employees - Jujutsu docs”</a> <a href="#user-content-fnref-contrib" data-footnote-backref="" aria-label="Back to reference 8">↩</a></p> </li> <li id="user-content-fn-jjcon-keynote"> <p><a href="youtube.com">“JJ Con • Keynote - YouTube”</a> <a href="#user-content-fnref-jjcon-keynote" data-footnote-backref="" aria-label="Back to reference 9">↩</a></p> </li> <li id="user-content-fn-other-tool"> <p><a href="docs.github.com">“Usar outras ferramentas com pull requests empilhados - Documentos do GitHub”</a> <a href="#user-content-fnref-other-tool" data-footnote-backref="" aria-label="Back to reference 10">↩</a></p> </li> <li id="user-content-fn-disc3021"> <p><a href="jj#3021">“Question: What’s ‘jujutsu’ from? · jj-vcs/jj · Discussion #3021”</a> <a href="#user-content-fnref-disc3021" data-footnote-backref="" aria-label="Back to reference 11">↩</a></p> </li> <li id="user-content-fn-disc2520"> <p><a href="jj#2520">“Proposal: Rename Jujutsu to Jojo · jj-vcs/jj · Discussion #2520”</a> <a href="#user-content-fnref-disc2520" data-footnote-backref="" aria-label="Back to reference 12">↩</a></p> </li> <li id="user-content-fn-pr3042"> <p><a href="jj#3042">“meta: cement “Jujutsu” (呪術) as the project name by thoughtpolice · Pull Request #3042 · jj-vcs/jj”</a> <a href="#user-content-fnref-pr3042" data-footnote-backref="" aria-label="Back to reference 13">↩</a></p> </li> </ol> </section>

Does Jujutsu Work with GitHub? Why the Name? 7 Questions Answered --- title: Does Jujutsu Work with GitHub? Why the Name? 7 Questions Answered published: true date: 2026-10-20 00:00:00 UTC tags: jujutsu,jj,git,github cover_image: dev-to-uploads.s3.us-east-2.amazonaws.com canonical_url: juju-chu.com --- Q1. Can I Use Jujutsu with My Existing Git Repositories? Yes. Jujutsu is highly compatible with Git, and running jj git init inside an existing Git repository is all it takes to start using Jujutsu there. You have nothing to lose by trying it, and you don’t have to give up Git. Jujutsu’s storage layer is pluggable, and Git is the default backend^{<a href="#user-content-fn-jj-plug" id="user-content-fnref-jj-plug" data-footnote-ref aria-describedby="footnote-label">1</a>}. The Git backend stores commits as ordinary Git objects, so the history you create with Jujutsu can also be accessed through Git tools. A repository where Jujutsu and Git live side by side is called colocated. You used to have to pass the --colocate option to jj git init, or to jj git clone when copying a remote repository, to get one. Since v0.34.0, released in October 2025, colocated is the default. You’ll still see --colocate in older articles, but you can safely skip it now. In a colocated repository, a .jj/ directory sits next to .git/ at the root. The .gitignore inside .jj/ contains /*, so adding Jujutsu doesn’t touch your root .gitignore. As mentioned above, your Git commit history keeps getting updated while you use Jujutsu, and you can push it to GitHub or any other remote as usual. Signed commits are supported too, so it works in repositories that require them. In other words, if you want to, you can be the only person on a Git team who uses Jujutsu. Git commands also keep working in a colocated repository. And if you decide Jujutsu isn’t for you, you can switch back to Git by deleting the .jj/ directory. Jujutsu leaves your existing Git setup as it is, which makes it about as cheap to try as a tool can be. Q2. What Can Git Do That Jujutsu Can’t? For all its Git compatibility, Jujutsu still doesn’t support some Git features, even in v0.46.0, the latest release as of October 2026. Three of them are the most likely to cause trouble in real projects: - Submodules - LFS (Large File Storage) - Git hooks or a direct equivalent The most serious of these is probably the lack of submodule support. Git submodules let you embed another independent Git repository as a subdirectory, usually to share code between projects. Lack of support doesn’t mean your submodule contents get lost. The problem is that they don’t follow you when you move through history. With jj edit, you can jump to any point in history like a time machine and view or edit files there, but submodule directories stay as they were. You have to run git submodule update --recursive by hand every time. Jujutsu also ignores changes you make inside a submodule, so recording them in history means running git add and git commit yourself. You can still work in a repository that has submodules, but you need to understand the limitations and handle the unsupported operations manually. On the development side, submodules don’t fit well with Jujutsu’s data model, and supporting them would require major design changes, which is a big reason support has lagged. It’s on the roadmap, but much of the design documentation is still unfinished, and there’s no implementation timeline in sight^{<a href="#user-content-fn-submod-sup" id="user-content-fnref-submod-sup" data-footnote-ref aria-describedby="footnote-label">2</a>}. These days, teams that need to share code often choose a monorepo or private packages on something like GitHub Packages instead of submodules. If you get to make that call, it’s worth considering those options for new projects. Git LFS is a Git extension for video, audio, large binaries, and other big files. It stores the large data outside the repository and keeps only pointers to it in Git. On GitHub, Git LFS is currently the only way to manage files over 100 MB in a repository^{<a href="#user-content-fn-gh-lg-file" id="user-content-fnref-gh-lg-file" data-footnote-ref aria-describedby="footnote-label">3</a>}. It’s widely used in fields like game development, and it isn’t supported either. Work is underway, with several PRs already submitted^{<a href="#user-content-fn-sup-lfs" id="user-content-fnref-sup-lfs" data-footnote-ref aria-describedby="footnote-label">4</a>}, but some design questions remain unresolved, including ones that affect other features. There’s still no clear timeline for a release. Finally, Git hooks. Hooks run your own scripts in response to specific Git actions, and far more teams rely on them than on the other two features. Typical uses are running formatters and linters before a commit, or tests and security audits before a push. Husky with lint-staged, and Lefthook, are the popular tools here. Jujutsu commands never trigger Git hooks. jj git push, for example, calls git push internally, but passes --no-verify to deliberately skip hooks^{<a href="#user-content-fn-no-verify" id="user-content-fnref-no-verify" data-footnote-ref aria-describedby="footnote-label">5</a>}. Officially, there’s no way to trigger Git hooks at a time of your choosing, and no Jujutsu-native hook mechanism either. The reason is that hooks don’t match Jujutsu’s core design and data model. A couple of factors stand out: - Jujutsu automatically commits your file changes as you work, so there’s no explicit commit step that hooks can run before. - Jujutsu rewrites code without going through your working directory, for example when you squash or when editing an old commit automatically rebases its descendants. Passing tests at the first commit doesn’t guarantee anything later on. While they don’t cover everything Git hooks can do, Jujutsu does offer a few official tools that fit its model. With jj fix, you register formatters in your config, and running it walks back through your mutable history and formats the files changed in each commit. jj run executes an external command against a single commit or a range of commits. You can use it to run builds or tests across your history, and since it writes any file changes the command makes back into the target commits, it also works for autofixing linters or other code-fixing tools. So what if your team has an elaborate hook setup built around Git and you want to be the only one using Jujutsu? There are several approaches depending on the situation, and the topic could easily fill an article or two, so I’ll skip it here. If you’re curious, my book _Juju-chu! Starting Your Jujutsu×AI Workflow with jj new_ covers this in section 4-3, “Alternative Tactics for Git Hooks.” Q3. Does Jujutsu Work with GitHub? It does. Because Jujutsu uses Git as its backend, it works fine whether your remote lives on GitHub, GitLab, or Bitbucket. The catch is that Jujutsu shares work through a different concept called a bookmark instead of a branch, and getting comfortable with that can be the real hurdle. Jujutsu has nothing that corresponds to Git’s named branches. You normally work on anonymous branches, and when it’s time to share, you put a bookmark on whichever commit you want. When you push a bookmarked commit to a remote, Git sees it as a branch. The confusing part is that GitHub treats it as a branch even though it’s a different concept that behaves differently. Newcomers often find these points surprising: - A bookmark doesn’t move to your latest commit automatically. You move it yourself. - A mechanism called tracking keeps a bookmark’s position, and its deletion, in sync between local and remote. - Tracking is practically essential, so local and remote bookmark names must match. - You can also create a bookmark on the fly at push time with the -c/--change or --named option, even if none exists yet. Why Jujutsu has bookmarks instead of branches, and what you gain by sharing work through them, is covered in detail in my previous post, “Jujutsu Has No “Create a Branch” Step, and That Finally Made Git Branches Click”. One way Jujutsu behaves differently from Git after you push: if you rewrite commits you’ve already pushed and push again, it becomes a force push without you doing anything special. Jujutsu always pushes in a way that’s close to --force-with-lease, and accidental rewrites are guarded against locally by whether each commit is mutable or immutable. By default, though, pushed commits outside of trunk are still mutable, so you can rewrite them, and pushing the result ends up as a force push. This can clash with the policy of teams that develop on shared feature branches. In that case, change which commits count as immutable with a setting like this^{<a href="#user-content-fn-other-immutable" id="user-content-fnref-other-immutable" data-footnote-ref aria-describedby="footnote-label">6</a>}: [revset-aliases] 'immutable_heads()' = 'builtin_immutable_heads() | remote_bookmarks("feature/*", "origin")' Beyond that, opening, approving, and merging PRs, and CI/CD with GitHub Actions and the like, work almost exactly the same with Jujutsu. About the only difference is that when you delete the remote branch on GitHub after merging a PR, the next jj git fetch deletes the linked local bookmark too. Q4. So What Does Jujutsu Actually Give You Over Git? Compared with Git, here’s what you get by switching to Jujutsu: - No index (staging area). There’s nothing like git add to run. - Commits happen automatically. Whenever you run a jj command and files have changed since the latest commit, Jujutsu takes a new snapshot and updates the commit. - Thanks to those two, the working copy (what Git calls the working tree) is treated as a commit in its own right. You can move around history like a time machine without worrying about uncommitted changes or keeping the index consistent, as you would in Git. - When you rewrite any commit, its descendants are rebased automatically. - However many conflicts a rebase hits, it finishes normally without dropping you into an interactive mode, leaving the conflicts in place. Because conflicted states are recorded in history , redoing a resolution or handing it to a tool is easy. - Apart from anything that touches a remote, jj undo can undo almost any operation. - Every jj command that changes the repository, and every automatic snapshot, is recorded in the operation log. Later, you can restore the repository to an earlier state or revert a specific operation. - No need to create and name a branch just to experiment. Start with jj new, and if you don’t like where it’s going, throw it away with jj abandon and try again. - The commands are straightforward and easy to remember. Squashing, for example, is jj squash --from A --into B. Options that specify what to operate on and where to put it, like -f/--from, -t/--into, -o/--onto, -A/--insert-after, and -B/--insert-before, work consistently across related commands. Q5. Is the Learning Curve Steep? You don’t need many commands to get started. With just these, you should be able to handle the whole basic workflow: | What you want to do | Command | | --- | --- | | Check the status | jj st | | View the log | jj log | | View the diff | jj diff | | Update the commit message | jj desc -m '...' | | Start the next piece of work | jj new | | Undo the last operation | jj undo | | Set a bookmark | jj bookmark set <name> | | Fetch from the remote | jj git fetch | | Push to the remote | jj git push -b <bookmark> | Even this much gets you the benefits of automatic commits and undo, and if those feel valuable, you’ve cleared the first hurdle. The trouble comes after that. The more Git experience people have, the more likely they are to use Jujutsu with their Git mental model intact, looking things up in a command mapping table^{<a href="#user-content-fn-git-cmd-table" id="user-content-fnref-git-cmd-table" data-footnote-ref aria-describedby="footnote-label">7</a>}. That way, you’re just translating Git operations one by one, missing much of what makes Jujutsu useful while adding the chore of translating commands. Jujutsu was designed to fix what makes Git hard to use. It stays compatible with Git but rethinks the mental model from the ground up. To get the most out of it, you have to follow Yoda’s advice: “You must unlearn what you have learned.” !A quote from Yoda That’s why the next stage is the hard part. The difficulty doesn’t come from Jujutsu being complicated. It comes from having to rethink version control habits you’ve built up over years with Git, and let go of concepts you’ve always taken for granted. Every now and then I see people who never realize this, keep running their Git workflow on top of Jujutsu, feel no benefit, and go back to Git. In my experience, focusing on these three things is the quickest way to develop a Jujutsu mental model: 1. Understand what a change is, Jujutsu’s usual unit of history - Think of a change as a container with a name and an ID that never changes, and of commits (also called revisions) as successive versions of a document stored inside it. It’s not technically precise, but it’s an easy picture for beginners 2. Drop the idea that you commit only once your work is finished - In Jujutsu, every time you change code or the description (roughly, the commit message), it’s as if git commit --amend --no-edit runs instantly and automatically. Changes are unfinished by default, and when you reach a stopping point, you simply move on to another change - Don’t use jj commit, which runs jj desc and then jj new in one step and exists to support Git-style workflows 3. Get used to not having a “current branch” while you work - Stick to one flow: work on an anonymous branch, and set a bookmark only when you want to share - Build the habit of checking where you are in the graph that jj log draws, instead of by branch name Once you let go of your Git workflow and keep working the Jujutsu way, the logic behind its design starts to click. By then, Jujutsu will feel like second nature, and you won’t want to work without it. Q6. Jujutsu Isn’t 1.0 Yet. Is It Safe to Use at Work? The short answer: if the issues in [Q2](#q2-what-can-git-do-that-jujutsu-cant) don’t affect you, there’s almost nothing stopping you in practice. The CLI and configuration will keep changing, though, so whether you can live with that is the real question when deciding to adopt it. The README in the official GitHub repository says: > 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. It also says that workflows may change and that backward-incompatible changes to the on-disk format may come before 1.0, adding that the project will try to provide transparent upgrades when the format changes. That might sound a little worrying, but there haven’t been any big breaking changes recently. Most of them have been removals of deprecated settings and command options, or changes to system requirements. v0.38.0, released in February 2026, moved where per-repository config files are stored, but that was for security reasons, a necessary step to protect users from malicious attacks. Martin von Zweigbergk, a former Google engineer, started Jujutsu as a side project in late 2019, and the first version on GitHub, v0.3.0, came out in March 2022. That’s four and a half years ago. Since v0.9.0 in September 2023, a new version has shipped almost every month. It may not be 1.0 yet, but it has a solid track record behind it. As of October 2026, the official GitHub repository has about 32,000 stars. The project has nine maintainers, and each release credits around 30 contributors. Engineers from several companies, Google among them, contribute on an ongoing basis, and the official docs list the companies that pay for Jujutsu contributions along with their contributing employees^{<a href="#user-content-fn-contrib" id="user-content-fnref-contrib" data-footnote-ref aria-describedby="footnote-label">8</a>}. What about real-world adoption? I mentioned that the creator came from Google. According to him, about 900 people inside Google were already using Jujutsu as of September 2025^{<a href="#user-content-fn-jjcon-keynote" id="user-content-fnref-jjcon-keynote" data-footnote-ref aria-describedby="footnote-label">9</a>}. In July 2026, he became CTO of ERSC, a hosting platform company whose storage is designed around Jujutsu’s model and which plans to support a native protocol for Jujutsu clients in the future. The fact that companies are building businesses with Jujutsu at their core is one good sign of its reliability. On top of that, GitHub stacked pull requests, which split a PR into a chain of small, dependent PRs, recently became generally available, and their documentation includes a page that walks through a workflow using Jujutsu^{<a href="#user-content-fn-other-tool" id="user-content-fnref-other-tool" data-footnote-ref aria-describedby="footnote-label">10</a>}. It’s fair to read this as a sign that GitHub sees Jujutsu as a compatible client with too many users to ignore, and one worth supporting. I don’t think Jujutsu is still pre-1.0 because of concerns about its quality or reliability. Rather, I suspect the developers want to keep the freedom to change its design while it continues to evolve. Many developers already use it every day, and companies continue to back its development. At the very least, being pre-1.0 is no reason on its own to avoid using it at work. Q7. Why Is It Called “Jujutsu”? A lot of people assume the name comes from the anime _Jujutsu Kaisen_. In Japan, it even gets teased on social media for sounding a bit edgy and over-the-top. But Jujutsu has nothing to do with _Jujutsu Kaisen_. So where does the name come from? The official README on GitHub suggests that the command name jj came first: > 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”. With your right index finger resting on J on the home row, it’s just two taps, so it really is easy to type. The README makes it sound as if Jujutsu was picked as a name that fits jj from the start, but the project actually had a different name at first. On crates.io, Rust’s official package registry, there’s a VCS called Jujube. Its author is Martin von Zweigbergk, and it has two versions, 0.1.0 and 0.1.1, released in January 2021. Yes, this is Jujutsu’s predecessor. Here’s what its page says about the name: > 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”. A jujube is a fruit, also known as a red date or Chinese date, and again it was chosen simply because it matched jj. Just four months later, the name changed. The commit message from that rename is still there: > 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 The author apparently had no particular attachment to Jujube, and switched to Jujutsu because it was more familiar and relatable. When someone later asked where the name came from^{<a href="#user-content-fn-disc3021" id="user-content-fnref-disc3021" data-footnote-ref aria-describedby="footnote-label">11</a>}, he pointed to the Wikipedia article on jujutsu, so it refers to the Japanese martial art. In English, the traditional Japanese art is usually spelled “jujutsu,” while “jiu-jitsu” is the spelling most people know from Brazilian jiu-jitsu. Wikipedia does have a separate Brazilian jiu-jitsu article, but searching for “jiu-jitsu” or “jiujitsu” redirects you to the jujutsu article. Without that redirect, the project might be called Jiu-jitsu today. So is it settled that the name means the martial art? Not quite. The author says he never gave the name any special meaning. When someone proposed renaming Jujutsu to Jojo^{<a href="#user-content-fn-disc2520" id="user-content-fnref-disc2520" data-footnote-ref aria-describedby="footnote-label">12</a>}, he didn’t seem very attached to Jujutsu either, suggesting they could hold a vote. There was also a proposal to officially adopt a different meaning and pronunciation^{<a href="#user-content-fn-pr3042" id="user-content-fnref-pr3042" data-footnote-ref aria-describedby="footnote-label">13</a>}. In Japanese, “jujutsu” can stand for two different words: 柔術 (jūjutsu, the martial art) and 呪術 (jujutsu, sorcery or curses, the word in _Jujutsu Kaisen_). The proposal was to make 呪術 the official one, and the author himself liked the idea at first. In the end, though, defining an official meaning or pronunciation was set aside. The official logo, in use since 2025, shows the same stance of not giving the name any particular meaning. !The Jujutsu logo Two blue birds sit back to back. They’re jays, members of the crow family. Put two of them together and you get “jay jay.” Not just the name, but the logo too is a pun on jj. If the martial art were the official meaning, the logo would surely show something related to it, but it doesn’t. In the end, it all started with jj, a short command name that’s easy to type. The project was named Jujutsu after the martial art, yet officially it means neither 柔術 nor 呪術. Jujutsu is just Jujutsu, and that’s probably the real answer to where the name comes from. Still Have Questions? Those are seven questions Git users are likely to have when they’re thinking about giving Jujutsu a try. Some of these answers are reworked from the FAQ in Chapter 5, “The Jujutsu Problem-Solving Guide,” of my book, _Juju-chu! Starting Your Jujutsu×AI Workflow with jj new_. {% embed juju-chu.com %} The book covers many more of the questions Jujutsu newcomers tend to have, along with how to deal with the problems you’re likely to run into once you start. If you’re getting started with Jujutsu, it should save you a lot of time, so please check it out. <section data-footnotes><h2 id="footnote-label">Footnotes</h2> <ol> <li id="user-content-fn-jj-plug"> <p>Besides Git, Jujutsu can also use <a href="en.wikipedia.org)">Piper</a>, the version control system used inside Google, as a backend, but that part isn’t public. A native Jujutsu backend seems to be on the wish list, but no concrete plan has been announced. <a href="#user-content-fnref-jj-plug" data-footnote-backref="" aria-label="Back to reference 1">↩</a></p> </li> <li id="user-content-fn-submod-sup"> <p><a href="docs.jj-vcs.dev">“Submodule support - Development roadmap - Jujutsu docs”</a> <a href="jj#494">“Add support for Git submodules · Issue #494 · jj-vcs/jj”</a> <a href="#user-content-fnref-submod-sup" data-footnote-backref="" aria-label="Back to reference 2">↩</a></p> </li> <li id="user-content-fn-gh-lg-file"> <p><a href="docs.github.com">“About large files on GitHub - GitHub Docs”</a> <a href="#user-content-fnref-gh-lg-file" data-footnote-backref="" aria-label="Back to reference 3">↩</a></p> </li> <li id="user-content-fn-sup-lfs"> <p><a href="jj#80">“Add support for Git LFS · Issue #80 · jj-vcs/jj”</a> <a href="#user-content-fnref-sup-lfs" data-footnote-backref="" aria-label="Back to reference 4">↩</a></p> </li> <li id="user-content-fn-no-verify"> <p><a href="github.com/jj-vcs/jj/blob/main/lib/src/git_subpro…">“jj/lib/src/git_subprocess.rs at main · jj-vcs/jj”</a> <a href="#user-content-fnref-no-verify" data-footnote-backref="" aria-label="Back to reference 5">↩</a></p> </li> <li id="user-content-fn-other-immutable"> <p>The official docs also show other settings, such as one that prevents you from rewriting commits created by other people. <a href="jj-vcs.dev">“Set of immutable commits - Configuration - Jujutsu docs”</a> <a href="#user-content-fnref-other-immutable" data-footnote-backref="" aria-label="Back to reference 6">↩</a></p> </li> <li id="user-content-fn-git-cmd-table"> <p>The official docs provide one too. <a href="docs.jj-vcs.dev">“Git command table - Jujutsu docs”</a> <a href="#user-content-fnref-git-cmd-table" data-footnote-backref="" aria-label="Back to reference 7">↩</a></p> </li> <li id="user-content-fn-contrib"> <p><a href="docs.jj-vcs.dev">“Paying employers and their contributing employees - Jujutsu docs”</a> <a href="#user-content-fnref-contrib" data-footnote-backref="" aria-label="Back to reference 8">↩</a></p> </li> <li id="user-content-fn-jjcon-keynote"> <p><a href="youtube.com">“JJ Con • Keynote - YouTube”</a> <a href="#user-content-fnref-jjcon-keynote" data-footnote-backref="" aria-label="Back to reference 9">↩</a></p> </li> <li id="user-content-fn-other-tool"> <p><a href="docs.github.com">“Use other tools with stacked pull requests - GitHub Docs”</a> <a href="#user-content-fnref-other-tool" data-footnote-backref="" aria-label="Back to reference 10">↩</a></p> </li> <li id="user-content-fn-disc3021"> <p><a href="jj#3021">“Question: What’s ‘jujutsu’ from? · jj-vcs/jj · Discussion #3021”</a> <a href="#user-content-fnref-disc3021" data-footnote-backref="" aria-label="Back to reference 11">↩</a></p> </li> <li id="user-content-fn-disc2520"> <p><a href="jj#2520">“Proposal: Rename Jujutsu to Jojo · jj-vcs/jj · Discussion #2520”</a> <a href="#user-content-fnref-disc2520" data-footnote-backref="" aria-label="Back to reference 12">↩</a></p> </li> <li id="user-content-fn-pr3042"> <p><a href="jj#3042">“meta: cement “Jujutsu” (呪術) as the project name by thoughtpolice · Pull Request #3042 · jj-vcs/jj”</a> <a href="#user-content-fnref-pr3042" data-footnote-backref="" aria-label="Back to reference 13">↩</a></p> </li> </ol> </section>

「GitHub で使える？」「なぜこの名前？」 Jujutsu の気になる 7 つの疑問 Q1. 既存の Git リポジトリがそのまま使える？ Jujutsu は Git と高い互換性を持っており、既存の Git リポジトリも jj git init コマンドで初期化することで Jujutsu で扱えるようになります。試してみるにあたって失うものは何もなく、Git を捨てる必要はありません。 Jujutsu はストレージ層が差し替え可能な設計で、デフォルトでは Git がそのバックエンドになっています1。Git バックエンドは commit を Git リポジトリに保存するため、Jujutsu で履歴を管理していても、Git インターフェースからはその履歴を Git の履歴として参照することができます。 Jujutsu リポジトリと Git リポジトリの共存は colocated という言葉で表現されます。リポジトリを colocated にするには、以前は初期化の jj git init やリモートリポジトリをローカルにコピーする jj git clone コマンドに --colocate オプションを渡さなくてはならなかったのですが、2025 年 10 月リリースの v0.34.0 からは colocated がデフォルトになり、その必要がなくなりました。古い記事などで逐一 --colocate オプションを指定している例を見かけますが、今となっては不要な記述なのでスルーしてください。 colocated なリポジトリのルートには、.git/ に加えて .jj/ ディレクトリが共存しています。.jj/ 配下の .gitignore に /* が記述されているため、ルートの .gitignore を汚すことなく Jujutsu を導入できます。先述したように Jujutsu を使っていても Git の commit 履歴は変わらず更新され続け、それを GitHub などのリモートリポジトリに push できます。署名付き commit にも対応しているため、署名を必須とするリポジトリでも利用できます。ですので、その気になれば Git を使っているチームで自分ひとりだけ Jujutsu を使うことが可能です。 また colocated なリポジトリでは、これまで通り Git コマンドも普通に使えます。もし Jujutsu を使うのをやめたくなったら、リポジトリルートの .jj/ ディレクトリを削除するだけです。このように Jujutsu は既存の Git の環境をそのままに、試してみるコストが非常に低いツールになっています。 Q2. Git にできて Jujutsu にできないことはある？ Git と高い互換性を持つ Jujutsu ですが、2026 年 10 月現在の最新 v0.46.0 でも未対応の Git の機能がいくつかあります。中でも実際の開発で問題になりやすいものとして、以下の 3 つが挙げられます。 submodules の管理 LFS（Large File Storage）の取り扱い Git hooks 相当の機能 このうちもっとも深刻なのが submodules をサポートしていないことでしょう。Git の submodules はリポジトリの中に別の独立した Git リポジトリをサブディレクトリとして組み込む機能であり、主にプロジェクト間でコードを共通化したい場合などに用いられます。 非対応といっても submodule の内容が失われるわけではないのですが、問題なのは履歴を移動しても submodule の内容が自動的に同期されないこと。Jujutsu では jj edit コマンドで、タイムマシンのように任意の履歴ポイントに移動してファイルを参照したり編集したりできますが、そのとき submodules のディレクトリの内容は追随してくれません。毎回手動で git submodule update --recursive を実行する必要があります。 またリポジトリで submodule の内容を変更しても、Jujutsu からは無視されてしまいます。そのため submodule における変更を履歴に載せるには、Git コマンドで add して commit する必要があります。このように Jujutsu で submodule を含むリポジトリをまったく運用できないわけではないのですが、何ができないかを正確に把握したうえで、毎回手動でフォローする手間が生じてしまいます。 また開発側の事情として、submodules は Jujutsu のデータモデルと相性が悪く、対応には大きな設計変更が求められるのも対応が遅れている大きな原因です。ロードマップには挙がっていますが、UX の面で大きな課題が未解決のまま残っていて、実装の見通しは立っていません2。なお近年は同じ目的でも submodules ではなく、モノレポや GitHub Packages などを利用したプライベートなパッケージ管理を選択することが増えているようです。もし技術選定ができる立場にいるのであれば、新規プロジェクトでは submodules を避けてそちらを検討したほうが良いでしょう。 Git LFS は動画や音声、大きなバイナリファイルなどを扱うための Git の拡張機能です。大容量データをリポジトリの外で管理し、Git 内にはそのポインタのみを保持するというしくみになっています。GitHub で 100MB を超えるファイルをリポジトリで直接管理するには、現状はこの Git LFS 一択となっています3。 ゲーム開発などでは必須とも言える機能ですが、これも現状で未対応です。開発自体は進んでいて PR がいくつも出ていますが4、他の機能も巻き込んでの設計判断が追いついていないようで、リリース時期はまだ見えません。 最後に Git hooks。Git の特定アクションに連動して独自のスクリプトを実行させるしくみであり、これは他の 2 つよりも導入している現場はずっと多いでしょう。commit の前にフォーマッターやリンターを実行させたり、push の前にテストやセキュリティの監査を実行させるといった用途に用いられます。併用されるツールとしては Husky + lint-staged や Lefthook がメジャーです。 しかし Jujutsu のコマンド実行によって Git hooks がトリガーされることはありません。たとえば jj git push は内部で git push コマンドを呼び出していますが、その際に --no-verify オプションを付けて hooks の実行を意図的に止めています5。そして公式からは、Git hooks を任意のタイミングでトリガーする機能も、それに相当する Jujutsu 独自の hooks 機能も提供されていないのです。 その理由は、hooks はそのしくみが Jujutsu のコアとなる設計思想やデータモデルとマッチしないことにあります。具体的には以下のような要因が挙げられるでしょう。 Jujutsu は随時ファイルの変更を検出して自動的に commit を行うため、Git のように儀式として commit を行うタイミングがない squash や過去の履歴を編集すると子孫に適用される自動 rebase など、Jujutsu では作業ディレクトリを経由せずにコードが書き換えられるため、最初の commit 時にテストなどをパスしていても、後々までそれを保証できない ただ Git hooks の機能をすべてカバーできるわけではありませんが、Jujutsu のモデルに適合したソリューションは公式からいくつか提供されています。たとえば jj fix は設定でフォーマッターを登録しておくと、実行時に編集可能な履歴を遡って、そこで変更されたファイルにフォーマットを適用してくれます。jj run は指定した履歴のポイントもしくは範囲に対して外部コマンドを実行するためのコマンドです。ビルドチェックやテストを巡回して実行するのに使える他、実行によって変更されたファイルを対象の履歴に反映できるため、修正を伴う静的解析などにも使えます。 しかし Git を前提に hooks 環境を作り込んでいるチームで自分だけ Jujutsu を使いたい場合はどうしたらいいのでしょう？　それには状況に応じたいくつかの対処方法があり、それだけで記事が 1〜2 本書けるほどのテーマなので、ここでは割愛させていただきます。なお拙著『じゅじゅちゅ！  jj new で始める Jujutsu × AI ワークフロー』の「4-3. Git Hooks の代替戦術」にその説明があるので、興味のある方はそちらを参照してください。 Q3. GitHub とも連携できるの？ Jujutsu は Git をバックエンドとして使えるため、リモートリポジトリが GitHub にあろうが GitLab にあろうが Bitbucket にあろうが、問題なく連携できます。しかし共有の単位に branch ではなく bookmark という異なる概念を用いるため、それを理解できるかどうかが障壁になるかもしれません。 Jujutsu では Git の名前付き branch に相当するものがなく、基本的に匿名 branch で作業を行い、共有時に任意の履歴ポイントに bookmark を付けるというワークフローになります。bookmark の付いた履歴をリモートリポジトリに push すると、Git からはそれが branch に見えるというしくみです。GitHub 上では branch として扱われるのに branch とは別の概念であり、その挙動も異なるのがややこしいところです。Jujutsu 初心者にとっては、以下の点に違和感を覚えるかもしれません。 自動で最新の履歴に移動せず、自分で動かす必要がある ローカルとリモートでその位置や削除を同期させる tracking というしくみがある tracking が前提のため、bookmark はリモートとローカルで同じ名前でなくてはならない bookmark がない状態からでも push 時に -c/--change や --named オプションを指定することで、その場で bookmark を作りながら push できる なぜ Jujutsu には branch がなく bookmark があるのか、bookmark による共有は何が嬉しいのかについては、前の記事の『「ブランチを切る」が Jujutsu にないと知って、初めてブランチを理解した話』でくわしく説明しているので、そちらを参照してください。 push した後のフローで Jujutsu の挙動が Git と異なる点に、push 済みの履歴を書き換えて再度 push すると、何もしなくても force push になってしまうことがあります。Jujutsu からの push は常に --force-with-lease オプションを指定しているのに近い挙動なのですが、履歴が意図せず書き換えられるリスクからはその commit が mutable（書き換え可能）か immutable（書き換え不可）かという判断によってローカルの段階から守られています。そのデフォルトの基準では trunk 以外では push 済みの commit でも mutable とされるため書き換えることができ、その結果を再度 push すると結果的に force push となってしまうのです。 これが feature branch を複数のメンバーで共有して開発する運用になっているチームのポリシーと競合することがあります。その場合は、たとえば以下のような設定で commit を immutable と判断する範囲を変更してあげるといいでしょう6。 [revset-aliases] 'immutable_heads()' = 'builtin_immutable_heads() | remote_bookmarks("feature/*", "origin")' その他 PR 作成やその承認とマージ、GitHub Actions などの CI/CD 周りについては Jujutsu を使っているからといってほとんど何も変わりません。ちがうのは PR マージ後にページからリモートの branch を削除すると、jj git fetch を実行したときに連動しているローカルの bookmark が削除されるくらいでしょうか。 Q4. けっきょく Jujutsu は Git と比べて何がうれしいの？ Git と比較したときの、Jujutsu を導入するメリットとしては以下のものが挙げられるでしょう。 インデックス（ステージングエリア）がない。git add に相当する操作が不要 commit が自動的に行われる。何らかの jj コマンドを実行した際、直近の commit からファイルが変更されていれば、新しくスナップショットを取って commit を更新するしくみ 上記 2 つの特徴により working copy（作業ディレクトリ）が commit そのものとして扱われる。それゆえ Git のように未 commit の変更やインデックスとの整合性を気にせず、タイムマシンのように自由に履歴上を移動できる 任意の履歴を書き換えると、その子孫の履歴が自動的に rebase される rebase の途中で conflict がいくつ発生しても、対話モードにならずいったん conflict を抱えた状態で正常終了する。すべての conflict を含んだ状態が履歴に残るため、解消のやり直しやツールに解消を任せるのが容易 リモートリポジトリに影響するものを除き、 jj undo でほとんどの操作を取り消せる リポジトリに更新があった各種 jj コマンドの実行や自動スナップショットの動作がすべて operation log に記録されている。後からファイルの状態をその操作直後の状態に戻したり、その操作だけを打ち消したりできる 実験や試行錯誤のために、いちいち作業の名前を考えて branch を作る必要がない。jj new で作業を始め、気に入らなければ jj abandon で破棄してやり直せる コマンド体系が素直でおぼえやすい。たとえば squash は jj squash --from A --into B。操作対象や移動先を指定するオプションも -f/--from、 -t/--into、-o/--onto、-A/--insert-after、-B/--insert-before など関連するコマンドで一貫している Q5. 学習コストは高い？ 最初におぼえるべきコマンドは、さほど多くありません。少なくとも以下のものを押さえておけば、一通りのワークフローはこなせるはずです。 やりたいこと コマンド 状態の確認 jj st ログの確認 jj log 差分の確認 jj diff 履歴のメッセージを更新 jj desc -m '...' 次の作業を始める jj new 直前の操作を取り消す jj undo bookmark をつける jj bookmark set <name> リモートからの取得 jj git fetch リモートへの push jj git push -b <bookmark> これだけでも自動 commit や undo 機能の恩恵は受けられるので、そこに価値を見出せれば第一関門は突破です。ただし問題はその先にあります。Git 経験者ほど Git のメンタルモデルのまま、コマンド対応表7を見ながら Jujutsu を使いがちです。しかしそれだと、ただ Git における操作を逐一翻訳しているだけのため Jujutsu の便利さを享受できないいっぽうで、面倒な翻訳プロセスが加わるだけになってしまいます。 Jujutsu は Git の使いづらさを解消するために、Git との互換性を保ちながらも、そのメンタルモデル自体を問い直して設計されています。Jujutsu のパワーを引き出すには、マスター・ヨーダの「You must unlearn what you have learned.（今まで学んだことを手放さねばならん）」という教えのようにする必要があるのです。 ですので、次の段階を超えるためのハードルは高くなります。しかしそれは Jujutsu が複雑だからというわけではなく、Git で長年培ってきたバージョン管理の習慣を見直し、当然だと考えてきた概念を捨て去ることを求められるためです。その必要性を認識できないまま、Git のワークフローをそのまま Jujutsu に置き換えて使い続けた結果、メリットを感じられず Git に戻ってしまう人をときどき見かけます。 Jujutsu のメンタルモデルを身につけるための近道として、個人的には以下の 3 つが肝要だと考えます。 Jujutsu の通常の履歴単位である change とは何かを理解する change は名前と不変の ID を持ったコンテナであり、commit（revision ともいう）はそこに格納される複数バージョンの書類と考えると、技術的には正確でなくとも初心者はイメージしやすい commit は作業が完成してから作るものという固定観念を捨てる Jujutsu ではコードを変更したり description（≒ commit メッセージ）を変更するたびに、自動的かつ瞬時に git commit --amend --no-edit が走るようなイメージ。change は未完成が常態であり、作業に区切りがついたら別の change に移動するだけ Git ワークフロー互換のために用意された jj desc → jj new をまとめて行う jj commit コマンドを使わない 作業中に「現在の branch」という概念がないことに慣れる 匿名 branch で作業して、共有したくなったらそこで bookmark をセットするというフローをひたすら守る 現在位置を branch 名ではなく、jj log で表示されるツリーグラフで確認する習慣を身につける 一度 Git のワークフローを手放して Jujutsu のやり方を続けていると、Jujutsu の設計の合理性が実感できるようになります。そのころにはもう Jujutsu はあなたの手足として、なくてはならないものになっているでしょう。 Q6. まだ v1.0 に達してないのに、業務で使って大丈夫？ 先に結論をいうと、Q2 の問題がクリアできるのであれば、実用上の問題はほぼありません。ただし CLI や設定方法は今後も変わり続けるので、それが許容できるかどうかが採用にあたっての焦点になるでしょう。 GitHub 公式リポジトリの README には以下のように書かれています。 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 は実験的なバージョン管理システム です。Git との互換性については安定しており、利用者の多くは日々の開発に必要な作業を Jujutsu でこなしています。しかし、まだ開発途中の機能や改善の余地がある UX、ワークフロー上の不足が残っており、用途によっては使用に耐えない可能性があります） そしてバージョン 1.0 のリリース前に、ワークフローの変更や後方互換性のないディスクフォーマットの変更があるかもしれないとも言っています。ただしフォーマット変更がある際には、透過的なアップグレードを用意するとのこと。 これだけ読むと少し不安になりますが、近年はさほど大きな破壊的変更はありません。破壊的変更の多くは非推奨だった設定やコマンドオプションの削除、動作環境の要件変更といったものです。2026 年 2 月リリースの v0.38.0 では、リポジトリ用設定ファイルの保存場所が変更されましたが、それもセキュリティ上の理由によるものであり、ユーザーを悪意ある攻撃から守るためにやむを得ないものでした。 Jujutsu は元 Google のエンジニアだった Martin von Zweigbergk 氏が 2019 年末からサイドプロジェクトとして開発を始め、GitHub で最初のバージョン v0.3.0 がリリースされたのが 2022 年 3 月のこと。そこからすでに 4 年半が経過していることになります。また 2023 年 9 月の v0.9.0 以降は、ほぼ毎月新バージョンをリリースしています。v1.0 に達してはいなくても、歴史的な積み重ねは十分にあると言っていいでしょう。 ちなみに GitHub の公式リポジトリのスター数は、2026 年 10 月現在で約 32,000 となっています。プロジェクトには現在 9 人のメンテナがいて、毎リリース 30 人前後のコントリビュータが名を連ねています。Google をはじめ、複数の企業に所属するエンジニアが継続的に開発に参加しています。公式ドキュメントには、Jujutsu の開発に業務として関わっている企業やその所属コントリビュータが公開されています8。 実績や採用事例はどうでしょうか？　先に作者は Google 出身と言いましたが、彼によると 2025 年 9 月の時点で Google 社内にはすでに 900 人ほどの Jujutsu ユーザーがいたそうです9。さらに彼は 2026 年 7 月に ERSC というホスティングプラットフォーム企業の CTO に就任しましたが、ERSC は独自ストレージの設計が Jujutsu のモデルに沿ったものとなっており、将来的には Jujutsu クライアントのネイティブプロトコルにも対応する構想です。Jujutsu をサービスに組み込んでビジネスを展開している企業が存在するのは、信頼性のひとつの目安となるでしょう。 また PR を親子関係を持った小さな単位に分割できる GitHub Stacked Pull Requests が先日から一般提供されるようになりましたが、そのドキュメントには Jujutsu を使ったフローを紹介したページがあります10。これは GitHub が Jujutsu を無視できない数のユーザーが使っている互換クライアントとして認識しており、サポートする必要性を感じていることの表れと見ていいでしょう。 Jujutsu がまだ v1.0 に達していないのは、品質や信頼性に問題があるからというよりも、まだ進化の途中にあり、仕様を変更する自由を残しておきたいという意味合いが強いのではないかと私は考えています。すでに多くの開発者による日常的な利用実績があり、企業による開発支援も続いています。少なくとも、v1.0 未満という理由だけで業務利用を避ける必要はないでしょう。 Q7. なんで「Jujutsu」という名前なの？ SNS などでよく「Jujutsu という名前が厨二病っぽい」という感想を目にします。おそらく漫画の『呪術廻戦』の影響でこの名前がつけられたと考えてのことなのでしょうが、Jujutsu は『呪術廻戦』とは関係がありません。 では Jujutsu という名前はどこから来たか。GitHub の公式 README からは、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". ホームポジションの右手人差し指で 2 回押すだけなので、確かにタイプしやすいですね。そしてそこから jj にマッチする Jujutsu がプロジェクト名としてつけられたように読めますが、実のところ初期のプロジェクト名は別のものでした。crates.io という Rust の公式なパッケージレジストリのサイトに、Jujubeという名前の VCS があります。作者は Martin von Zweigbergk 氏で、2021 年 1 月にリリースされた 0.1.0 と 0.1.1 のバージョンが登録されています。そう、これは Jujutsu の前身のプロジェクトなのです。ページには名前の由来について、以下のように書かれています。 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". jujube とは果物のナツメのことで、やはり jj にマッチする名前だから付けたのだとあります。しかしこのわずか 4 ヶ月後に名前が変えられました。そのときの commit メッセージが残っています。 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 どうやら作者として Jujube という名前には特に思い入れがなかったようで、より馴染みがあり親しみやすいという理由で Jujutsu にしたとのこと。後にこの名前はどこから来ているのかと質問された際11、Wikipedia の jujutsu のページを示しているので、これは武道の「柔術」のことでしょう。ちなみに英語では日本の古流柔術を「jujutsu」、ブラジリアン柔術を「jiu-jitsu」と表記することが多いようです。Wikipedia にはブラジリアン柔術（Brazilian jiu-jitsu）のページもあるのですが、「jiu-jitsu」や「jiujitsu」で検索すると jujutsu のページにリダイレクトされます。もしこの仕様がなかったら、今ごろは Jujutsu ではなく Jiu-jitsu になっていたかもしれません。 じゃあ Jujutsu は「柔術」が名前の由来ということで決定なのか。しかし彼はこの名前に特別な意味を持たせてないと言います。Jujutsu を Jojo に改名したいという提案があったときも12、やはり Jujutsu という名前にもさして執着がないのか、投票で決めたらいいというようなことを言っています。公式のミーニングや発音として「呪術」を採用してはどうかという提案があったときも13、作者自身は当初その案に好意的でした。しかし議論の結果、特定の意味や発音を公式に定義することは見送られました。 さらに 2025 年から使われている Jujutsu の公式ロゴからも、プロジェクト名に特別な意味を持たせていないという公式の姿勢が読み取れます。 青い鳥が 2 羽、背中合わせになっています。これはカラスの仲間のカケスという鳥です。英語では jay と言います。そう、2 つ並べると「jay-jay」。名前だけでなく、ロゴまで jj に引っかけたダジャレになっているのです。もし柔術が公式のミーニングであれば、それにまつわるものをロゴにしたはずですが、実際はそうなっていません。 結局のところ、すべては短くてタイプしやすい jj というコマンド名から始まったわけです。そこから武道の「柔術」にちなんで Jujutsu と名付けられたものの、公式には「柔術」とも「呪術」とも定義されていません。Jujutsu は Jujutsu でしかない。それが、この名前の由来に対する答えなのでしょう。 まだまだ疑問が解消されない方へ 以上、主に Git ユーザーが Jujutsu を試してみようかというときに気になるだろう 7 つの疑問をピックアップして回答しました。なお、この内のいくつかは拙著 『じゅじゅちゅ！  jj new で始める Jujutsu × AI ワークフロー』 の「第 5 章  Jujutsu 問題解決ガイド」に掲載されている一問一答を再構成した形になっています。 juju-chu.com 本書ではさらに Jujutsu 初心者が抱きがちな疑問や、いざ始めてみたときにぶつかりやすい問題への対処法などを豊富に掲載しています。Jujutsu を始める際に非常に役に立つ本になっていますので、ぜひチェックしてみてください。 脚注 Jujutsu は Git 以外にも、Google の社内で使われている Piper をバックエンドにすることもできますが、その部分は社外には公開されていません。Jujutsu ネイティブなバックエンドは構想としてはあるようですが、具体的なプランは示されていません。 ↩︎ 「Submodule support - Development roadmap - Jujutsu docs」 「Add support for Git submodules · Issue #494 · jj-vcs/jj」 ↩︎ 「GitHub での大きいファイルについて - GitHubドキュメント」 ↩︎ 「Add support for Git LFS · Issue #80 · jj-vcs/jj」 ↩︎ 「jj/lib/src/git_subprocess.rs at main · jj-vcs/jj」 ↩︎ その他にも、公式ドキュメントには他のユーザーが作成した commit の書き換えを防止するための設定などが紹介されています。 「Set of immutable commits - Configuration - Jujutsu docs」 ↩︎ 公式ドキュメントでも提供されています。「Git command table - Jujutsu docs」 ↩︎ 「Paying employers and their contributing employees - Jujutsu docs」 ↩︎ 「JJ Con • Keynote - YouTube」 ↩︎ 「他のツールで積み上げプルリクエストを使用する - 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 ↩︎

@GeoffreyHuntley Thinking of using this if you have a massive swarm of agents on a single task in different worktree, - jj-vcs/jj

Jujutsu (jj) GitHub Overview: Working-Copy Commits, Change IDs, and Undo jj by jj-vcs: jj-vcs/jj Jujutsu (jj) is a version-control interface designed to work with existing Git repositories while treating the working copy as a mutable commit. This overview contrasts automatic snapshots with Git's staging area, references the Git 2.42.0 prerequisite and cross-platform installation sources, and shows identity configuration, a colocated Project Helios workspace, jj status, jj commit, jj log, stable change IDs, the operation log, and jj undo. It closes with a look at automated descendant rebasing and non-blocking conflicts. Limitations and collaboration trade-offs are not covered here. TimeStamps: 0:00 Why standard Git workflows can stall 0:33 Working copy as a mutable commit 0:46 Removing the staging step 1:12 Git 2.42.0 and CLI prerequisites 1:58 Identity configuration and a colocated workspace 3:20 Automatic tracking: status and commit 3:48 Change IDs in the repository graph 4:24 Operation log and undo 5:08 Automated rebasing and non-blocking conflicts 5:39 Git-compatible workflow wrap-up 🧩 Working-copy commits remove manual staging 🧭 Stable change IDs support history reorganization ↩️ Operation logs make repository undo visible 🔀 Rebasing and conflict handling preview Jujutsu's working-copy model is aimed at developers who want fewer staging decisions in a Git-centered workflow. The video gives a concise orientation to setup, snapshots, history, and recovery concepts, while the final preview points toward rebasing and deferred conflict work. Use the official repository and documentation to evaluate current behavior and workflow fit. #Jujutsu #Git #VersionControl

Agit should work over ssh with git lfs (I could only find issues with http). I did not change anything here, but I know that LFS changes are being made. git lfs objects impacts the storage like normal git objects (even though the underlying storage may have another quota). In Forgejo (unlike github afaik) forks completely duplicate this storage. Having Agit PR (unlike fork-based PRs) allows to prevent this useless duplication (from a hoster point of view). From a repo owner point of view, it balloons the storage (like a fork-based PR), but since you are now allowed to (force) push to the PR, you should be able to cleanup those objects (from LFS as well once they have been made unreachable). I am not well versed into the LFS topic and I think it would be great if you could give this a try and report your experience ! v16.next.forgejo.org (if you plan to upload a large repo, please ping in matrix first, to not get banned :) --- JJ does not support agit at all yet: jj#4388