O Jujutsu funciona com o GitHub? De onde vem o nome? 7 perguntas e respostas

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¹. 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². 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³.

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⁴, 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⁵. 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⁶:

[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:

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⁷. 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.”

É 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 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⁸.

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⁹. 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¹⁰. É 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¹¹, 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¹², 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¹³. 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.

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`.

Juju-chu! — O guia de Jujutsu para programar com agentesUm guia prático para adotar Jujutsu (jj) com Claude Code e Codex: snapshots automáticos, operações que podem ser desfeitas e reescrita segura do histórico.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.