DEV Community: Juju-chu! Blog (pt)

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

Yuka Ooka — Tue, 20 Oct 2026 00:00:00 +0000

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:

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

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
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
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! — Comece seu fluxo de trabalho Jujutsu × IA com jj new

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

Footnotes

Além do Git, o Jujutsu também pode usar como backend o Piper, 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. ↩
“Submodule support - Development roadmap - Jujutsu docs” “Add support for Git submodules · Issue #494 · jj-vcs/jj” ↩
“Sobre arquivos grandes no GitHub - Documentos do GitHub” ↩
“Add support for Git LFS · Issue #80 · jj-vcs/jj” ↩
“jj/lib/src/git_subprocess.rs at main · jj-vcs/jj” ↩
A documentação oficial também mostra outras configurações, como uma que impede reescrever commits criados por outras pessoas. “Set of immutable commits - Configuration - Jujutsu docs” ↩
A documentação oficial também tem uma. “Git command table - Jujutsu docs” ↩
“Paying employers and their contributing employees - Jujutsu docs” ↩
“JJ Con • Keynote - YouTube” ↩
“Usar outras ferramentas com pull requests empilhados - Documentos do 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” ↩

O Jujutsu não tem o passo de “criar um branch”, e foi isso que finalmente me fez entender os branches do Git

Yuka Ooka — Tue, 13 Oct 2026 12:44:00 +0000

O Jujutsu não tem branches?

Quando comecei a usar o Jujutsu depois de anos seguindo os fluxos de trabalho do Git, a primeira coisa que me deixou perdida foi que não havia nenhum branch ao qual o meu trabalho atual pertencesse. Todo mundo que começa no Git aprende o ritual: antes de fazer qualquer trabalho de verdade, crie um branch. Mesmo num projeto pessoal em que você pula essa etapa, pelo menos você está no branch main.

Só que a documentação oficial e um tutorial bastante conhecido já começam direto no trabalho. Ninguém cria um branch nem troca de branch. Na verdade, por mais que eu procurasse, não encontrava no Jujutsu nada chamado “branch” que desse para manipular. No lugar disso existe uma coisa chamada bookmark , que é mapeado para um branch quando você trabalha com o Git. E, mesmo assim, um bookmark não é a mesma coisa que um branch. Eu não estava entendendo nada.

Mas, depois de fazer push do meu trabalho no Jujutsu e abrir PRs com ele algumas vezes seguindo os guias, me ocorreu uma coisa: talvez o Git e o Jujutsu simplesmente queiram dizer coisas diferentes com a palavra “branch”. Com isso em mente, reli o capítulo sobre branches do Pro Git¹ e a página sobre bookmarks da documentação do Jujutsu, e finalmente a ficha caiu. Um branch do Git não é um “galho” no sentido literal, e faz todo o sentido o Jujutsu chamar o equivalente dele de “bookmark”.

O que “um branch do Git é um ponteiro” quer dizer de verdade

Afinal, o que é exatamente um branch do Git? A seção 3.1 do livro Pro Git descreve o branching assim:

Branching (ramificação) significa que você diverge da linha principal de desenvolvimento e continua a fazer o trabalho sem mexer nessa linha principal.

Lendo um pouco mais adiante, você encontra isto:

Um branch no Git é simplesmente um ponteiro móvel e leve para um desses commits.

[…]

O que acontece quando você cria um novo branch? Bem, fazer isso cria um novo ponteiro para você mover por aí.

“Um branch é um ponteiro.” Se você usa Git há algum tempo, com certeza já ouviu essa frase. Confesso, meio sem graça, que ela nunca me disse muita coisa, e por anos usei branches no feeling. Hoje entendo o porquê. A explicação se apoia em várias premissas que ninguém menciona, e, para quem teve o Git como primeiro VCS, ela não diz muito. A documentação oficial do Git e os livros clássicos foram escritos por veteranos que conheciam bem outros sistemas de controle de versões, e é fácil eles não perceberem que quem começou pelo Git não compartilha essas premissas.

Então, o que é preciso saber para que “um branch é um ponteiro” faça sentido? A primeira coisa é que, no Git, um branch não é a bifurcação do histórico em si. Para separar as duas coisas, o Pro Git usa expressões como “histórico divergente” (divergent history) para se referir à bifurcação propriamente dita².

A maioria dos VCSs distribuídos representa o histórico como um DAG³, e não como uma árvore, então as bifurcações e os merges são expressos inteiramente dentro do grafo. O que muda de um VCS para outro é o mecanismo que ele oferece ao usuário para visualizar e manipular essas bifurcações, e a maioria chama esse mecanismo de “branch”. No Mercurial, que surgiu mais ou menos na mesma época que o Git, um branch é um metadado gravado de forma permanente em cada commit de uma linha do histórico. Já o Git usa um ponteiro para cada linha do histórico, e cada um aponta para um único commit.

Ainda não ficou claro? Então vamos para a segunda premissa. O que diferencia o Git de outros VCSs é que, onde quer que você esteja, ele sempre te empurra automaticamente para a ponta do histórico. Nos VCSs anteriores, criar branches e alternar entre eles eram operações pesadas, que atrasavam bastante projetos grandes como o kernel do Linux. Torná-las extremamente rápidas foi um dos objetivos centrais quando o Git foi projetado. A solução foi transformar o branch num ponteiro móvel para um único commit, guardado num arquivo de texto de apenas algumas dezenas de bytes.

Para isso funcionar, o Git espera que você edite o código na linha de trabalho para a qual algum branch aponta, e o ponteiro do branch avança automaticamente a cada novo commit. Trocar de branch significa fazer o HEAD, o ponteiro que indica onde você está, coincidir com esse branch. Por isso, no Git, para onde quer que você vá, acaba sempre empurrado para a ponta do histórico.

Como o Git era o único VCS distribuído que eu conhecia, achava que todos funcionavam assim. Descobrir que esse comportamento é específico do Git, e entender o mecanismo por trás dele, foi o que finalmente me fez entender o que significa dizer que um branch do Git é um ponteiro.

O que acontece com uma bifurcação do histórico sem branch?

Então, o Git pode ter uma bifurcação do histórico que não seja um branch? Criar uma é bem fácil: faça checkout de um commit antigo pelo hash.

$ git checkout 9effb1cc737824d9c14e1a8ecbb725e44ccae104
Note: switching to '9effb1cc737824d9c14e1a8ecbb725e44ccae104'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
⋮
HEAD is now at 9effb1c create b.txt

$ echo '444' > d.txt
$ git add .
$ git commit -m 'create d.txt'
[detached HEAD 46b43c3] create d.txt
 1 file changed, 1 insertion(+)
 create mode 100644 d.txt

O Git faz questão de avisar que agora você está em estado de detached HEAD (HEAD desanexado). Normalmente o HEAD aponta para algum branch. Quando ele aponta diretamente para o hash de um commit específico, isso se chama detached HEAD. Empilhar commits nesse estado é considerado arriscado e é melhor evitar, porque esse histórico acaba assim:

Você não consegue encontrá-lo depois
Ele é tratado como lixo e acaba sendo apagado
Você não consegue compartilhá-lo com ninguém

No Git, os commits só passam a ser rastreáveis por pessoas quando pertencem a um branch ou a uma tag. Os commits feitos em detached HEAD perdem a referência assim que você troca de branch, e não aparecem nem no git log --all. O reflog é a única forma de recuperá-los. Além disso, o sistema os trata como histórico desnecessário e eles ficam sujeitos à coleta de lixo, então, quando o prazo expira, somem de vez. Commits que você mesmo pode perder de vista com facilidade, e que podem sumir a qualquer momento, naturalmente são difíceis de compartilhar com outras pessoas.

Por que o Jujutsu tem bookmarks em vez de branches

Como comentei no começo, o Jujutsu não tem nada chamado “branch” que dê para manipular. Mesmo assim, a palavra “branch” aparece o tempo todo na documentação dele, no sentido literal de bifurcação do histórico. O Jujutsu não tem o conceito de “branch atual” nem nenhum mecanismo próprio para identificar bifurcações do histórico, então “branch” é usado no seu sentido original e literal.

Então, por que o Jujutsu não tem branches como os do Git e do Mercurial? No Git, fazer amend ou rebase de um commit gera um hash completamente novo. Hashes que mudam o tempo todo são difíceis de acompanhar, tanto para o sistema quanto para as pessoas, então um commit precisa pertencer a um branch: um rótulo nomeado e estável que diz em qual linha de trabalho ele está. No Jujutsu, por outro lado, a unidade básica do histórico, o change, tem um change ID imutável , separado do commit ID, que muda sempre que o change é revisado. Não importa quantas vezes você reescreva o conteúdo ou faça rebase, dá para acompanhar um change pelo mesmo ID, então quase não há necessidade de rotular cada linha de trabalho.

Além disso, as bifurcações do histórico sempre aparecem no log como um grafo em arte ASCII. Entre o grafo que você vê no log e as descrições dos changes que formam os nós dele, dá para ver de cara a qual linha de trabalho cada change pertence. E qualquer change que tenha descrição ou que modifique arquivos fica no histórico até você descartá-lo explicitamente.

Como os branches não têm nome, o normal no Jujutsu é trabalhar no equivalente ao detached HEAD do Git. O Jujutsu chama isso de branch anônimo (anonymous branch). O detached HEAD é considerado perigoso, mas os branches anônimos do Jujutsu não têm os dois primeiros problemas que ele tem no Git: “1. Você não consegue encontrá-lo depois” e “2. Ele é tratado como lixo e acaba sendo apagado”. E o “3. Você não consegue compartilhá-lo com ninguém”? É para isso que o Jujutsu oferece os bookmarks.

Um bookmark é um ponteiro nomeado associado a um change. Tanto os bookmarks quanto os branches do Git são ponteiros nomeados, mas, diferente de um branch do Git, um bookmark é apenas uma marcação para compartilhar com outras pessoas ou para você não esquecer de algo, sem relação direta com as bifurcações do histórico. É por isso que você pode colocar vários bookmarks na mesma linha de trabalho, e também por isso que, quando você cria novos changes sobre esse change, um bookmark não avança sozinho como um branch do Git.

O Jujutsu não vê necessidade de dar nome às bifurcações do histórico, nem de apontar uma linha de trabalho divergente inteira só para compartilhar histórico com outras pessoas. É por isso que o Jujutsu tem bookmarks em vez de branches.

Branches anônimos + bookmarks: até onde a evolução dos VCSs chegou

No Git, tanto criar bifurcações do histórico quanto fazer merge delas acontece, basicamente, no nível do branch. E como o Jujutsu, que não tem branches, lida com isso?

No Jujutsu, o comando que cria um change novo, a unidade básica do histórico, é o jj new. Como criar uma bifurcação do histórico? Passe para o jj new o ID de um change que já tem um filho. Como fazer merge de um histórico que divergiu? Passe para o jj new os IDs dos changes que você quer juntar. No Jujutsu, estender o histórico, bifurcá-lo e fazer merge funcionam no nível do change , e, surpreendentemente, tudo é a mesma operação básica: criar um change novo.

Você segue trabalhando assim até um ponto em que faz sentido parar. Hora de abrir um PR. É só agora que você precisa de fato dar um nome a essa linha de trabalho⁴. Coloque um bookmark num change e faça push, e toda a sequência de changes, desde o ponto em que ela saiu da main até esse change, é registrada como um branch no repositório Git remoto, com cada change convertido num commit do Git.

O que você ganha quando a unidade de compartilhamento não está presa a branches? Primeiro, flexibilidade: você pode começar a trabalhar sem decidir um nome nem o que vai compartilhar, e resolver essas questões só quando chegar a hora de compartilhar. Segundo, fica fácil montar uma série de PRs dependentes, algo que ficou bem mais valioso nos últimos tempos. Os stacked pull requests do GitHub, que permitem dividir um PR em unidades pequenas com relações de pai e filho, finalmente ficaram disponíveis para todos em 6 de outubro de 2026⁵, e os bookmarks do Jujutsu deixam muito fácil trabalhar com eles. Para montar stacked PRs com o Git, você cria o primeiro branch com gh stack init, cria um branch filho com gh stack add toda vez que termina uma parte do trabalho e, no fim, faz push e abre os PRs com gh stack submit. É um processo bem trabalhoso e muito dependente de ferramentas específicas. Com o Jujutsu, você coloca bookmarks em ordem na sua linha de trabalho, faz push e roda algo como gh stack link <bookmark1> <bookmark2> <bookmark3>. Só isso. É tão simples que chega a ser anticlimático.

Sem branches, o Jujutsu repensou as operações que o Git tinha construído em torno deles, para que você possa trabalhar em unidades menores e mais flexíveis. Depois de conviver um tempo com um Jujutsu sem branches, finalmente entendi o que são os branches do Git, depois de anos usando-os com uma ideia nebulosa. E aí os conceitos do Jujutsu, tão diferentes dos do Git, começaram a me parecer surpreendentemente racionais. Essa sensação fica ainda mais forte quando você olha a história dos VCSs com certo distanciamento.

Comentei antes que o Mercurial tem um tipo de branch diferente do Git. Mas, como os branches do Mercurial são dados permanentes e globais gravados em cada commit, eles não combinam bem com o desenvolvimento de funcionalidades ou correções de bugs que terminam em poucos dias. Por isso os bookmarks foram adicionados depois, para o trabalho mais leve: marcadores do tipo ponteiro que serviam para repassar o trabalho no push ou para marcar onde você estava trabalhando. Inspirados nos branches do Git, mas independentes dos branches do Mercurial e pensados para o compartilhamento. É daí que vêm os bookmarks do Jujutsu.

O Jujutsu vai um passo além: considera os branches desnecessários para as bifurcações do histórico e simplesmente não os tem. Curiosamente, o Sapling, que a Meta criou a partir de um fork do Mercurial e desenvolveu por conta própria, também não tem branches, mas tem bookmarks. Dá para dizer que “branches anônimos + bookmarks” é um dos pontos a que a evolução do controle de versões chegou, do Git ao Jujutsu, passando pelo Mercurial.

Uma última observação: este post é baseado nas seções “2-4-2. A diferença entre branch e bookmark” e “2-4-3. Trabalhando em branches anônimos” do meu livro, Juju-chu! — Comece seu fluxo de trabalho Jujutsu × IA com jj new.

Juju-chu! — Comece seu fluxo de trabalho Jujutsu × IA com jj new

Um 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

Os primeiros capítulos do livro se concentram na diferença entre os modelos mentais do Git e do Jujutsu. Além de branches versus bookmarks, eles explicam com cuidado os outros pontos em que quem está começando costuma tropeçar. Se este post te deu vontade de experimentar o Jujutsu, ou de dar mais uma chance a ele se da primeira vez não engrenou, dê uma olhada.

Footnotes

Livro de código aberto sobre Git, escrito por Scott Chacon e Ben Straub, que também é usado como documentação oficial do Git. Ele pode ser lido gratuitamente online. https://git-scm.com/book/pt-br/v2 ↩
https://git-scm.com/book/pt-br/v2/Ramifica%c3%a7%c3%a3o-Branching-no-Git-Branches-em-Poucas-Palavras#divergent_history ↩
Sigla em inglês de Directed Acyclic Graph (grafo acíclico dirigido): uma estrutura de grafo em que os nós, ligados por arestas com direção, nunca formam um ciclo. ↩
Se você prefere dar um nome logo de início, claro que também dá. Crie um bookmark com jj bookmark create ao começar o trabalho e, antes de fazer push, mova-o para o change desejado com jj bookmark move ou jj bookmark advance. ↩
Stacked pull requests generally available - GitHub Changelog ↩

Por que continuo escolhendo o Jujutsu mesmo com a IA cuidando do Git

Yuka Ooka — Tue, 06 Oct 2026 12:48:00 +0000

“Se um agente de IA já cuida do Git para você, por que aprender outro sistema de controle de versões, como o Jujutsu?”

Essa foi a objeção mais comum ao meu último post, 15 anos de Git e depois Jujutsu: por que não consigo mais voltar. É uma dúvida legítima, e também interessante, então este post é a minha resposta.

Concordo que o controle de versões do dia a dia é trabalho para um agente de IA. É exatamente assim que eu trabalho. A diferença é que os comandos que meus agentes executam são do Jujutsu, não do Git. Depois de experimentar os dois jeitos, estou convencida de que, mesmo com a IA no comando, o Jujutsu oferece uma experiência de desenvolvimento muito melhor, e de que o tempo investido para aprendê-lo se paga rapidamente.

Antes de apresentar meus argumentos, vale esclarecer logo uma dúvida óbvia: a IA consegue mesmo lidar com o Jujutsu? Testei com Opus, GPT, Gemini e outros. Os modelos mais recentes já conhecem nativamente os conceitos básicos e os principais comandos do Jujutsu, e conseguem cuidar das operações do dia a dia sem carregar nenhuma skill extra. Dito isso, o Jujutsu não está tão integrado às ferramentas dos agentes quanto o Git, então é preciso alguma configuração para impedir que o agente volte ao Git sem avisar e para ensinar a ele um fluxo de trabalho adequado ao Jujutsu. Esta é a configuração que eu uso.

A cerimônia do commit no Git versus os changes sem atrito do Jujutsu

No Git, a unidade básica do histórico é o commit. O fluxo padrão é assim: você edita arquivos na working tree, escolhe os que quer e os adiciona ao índice, depois escreve uma mensagem e cria um commit. Só então algo entra no histórico. Um commit foi pensado para ser um produto acabado, algo feito com cuidado, e é por isso que o Git oferece o índice como staging area. Editar um arquivo e registrar essas alterações no histórico exige uma sequência longa e rígida de passos. É quase um ritual.

Então, mesmo quando você entrega o Git a uma IA, continua terminando cada tarefa com o pedido “faça o commit disso”. Peça qualquer operação no histórico no meio de uma tarefa e lá vem a troca de sempre: “Há alterações sem commit. Devo guardá-las no stash ou fazer o commit primeiro?”. Cada rodada talvez leve só meio minuto, mas acontece o tempo todo, e tudo isso vai somando. Há também um custo cognitivo, pago tanto por você quanto pela IA, mesmo que você não perceba.

No Jujutsu, a unidade básica do histórico é o change. Quando você inicializa um repositório, começa em um change vazio. Cada edição que você faz ali é salva, conforme você trabalha, como uma nova revisão desse change¹. Você pode adicionar uma descrição, o equivalente no Jujutsu a uma mensagem de commit, quando quiser. Um change nunca tem um momento em que fica oficialmente “pronto”². Quando termina o trabalho, você simplesmente segue em frente.

Isso significa que, quando uma IA opera o Jujutsu por você, basta deixar uma instrução fixa: começar cada tarefa em um change novo, com uma descrição³. A partir daí, você só diz “crie a funcionalidade X”, e o histórico fica dividido em unidades razoáveis que acompanham o fluxo do trabalho. Chega de “faça o commit disso” no fim de cada tarefa, e chega de ter que arrumar a cópia de trabalho antes de uma operação no histórico.

O Jujutsu é compatível com o Git, mas não existe índice entre o seu diretório de trabalho e o seu repositório local. Além disso, o estado do seu diretório de trabalho é o ponto atual do histórico (o Jujutsu chama isso de “working copy as a commit”, a cópia de trabalho como commit). No Git, tanto pessoas quanto a IA precisam acompanhar três estados para cada alteração em um arquivo. No Jujutsu, normalmente há só um. Só depois de migrar percebi quanto esforço mental extra eu gastava para me adaptar ao jeito do Git de fazer as coisas, e como todo aquele controle era estressante.

Alguns de vocês vão dizer que isso não incomoda nem um pouco. Tudo bem. Muita gente realmente não se importa de vestir terno e chegar ao escritório às 8h30 todas as manhãs. Mas imagine sair disso para um emprego sem código de vestimenta, com horário flexível e trabalho remoto até três dias por semana, e achar tudo tão confortável que não daria mais para voltar. Foi isso que senti com a mudança.

O Jujutsu facilita desfazer os erros da IA

Pessoas erram, e a IA também. Ainda vejo, de vez em quando, relatos de agentes de IA que apagaram arquivos em que alguém estava trabalhando, sem nenhum jeito de recuperá-los. Peça a um agente para resolver um conflito e não é raro receber um resultado que passa nos testes, mas está semanticamente quebrado. E como as instruções aos agentes são dadas em linguagem natural, um prompt nem sempre transmite bem a sua intenção, então muitas vezes você não vai ficar satisfeito com o que recebe.

Quando a IA executa comandos do Git como parte do trabalho, recuperar-se de um resultado ruim fica muito mais difícil. O Git não tem como voltar o repositório inteiro ao estado em que estava antes de uma determinada operação. Como mencionei, o Git guarda estado em vários lugares: a working tree, o índice, o stash e os commits, e cada um tem sua própria forma de proteção, quando existe alguma. Rebase, amend e squash não modificam os commits existentes. Eles criam commits novos e movem o branch para eles, de modo que os originais deixam de ser referenciados por qualquer branch. Eles continuam no reflog, mas encontrar depois a entrada certa, enterrada no meio de todo o resto, é uma verdadeira dor de cabeça.

Para compensar o fato de o Git não salvar alterações sem commit, o Claude Code oferece o comando /rewind, que volta o código a um ponto anterior junto com a conversa. Mas ele não combina bem com um agente que executa comandos do Git. Seus arquivos voltam, mas o estado do Git não, então de repente o git status mostra uma pilha de alterações que você nunca quis, e lá vai você arrumar o histórico de novo. E o que tiver sido alterado por comandos do shell, por você ou por outros agentes rodando em paralelo não é revertido de jeito nenhum.

Se você percebe um erro na hora, ainda está numa boa. Mas o mais comum é ele aparecer depois, quando você roda os testes após continuar trabalhando ou quando revisa as coisas dias mais tarde. A essa altura, fica muito mais difícil desembaraçar tudo. Mais operações se acumularam em cima da errada e, mesmo que você mergulhe de cabeça no reflog, nada garante que uma longa série de passos delicados vai resolver. Pior: o Git não oferece nenhum jeito de desfazer a própria tentativa de recuperação. Uma IA que tenta uma correção atrás da outra para sair do buraco pode facilmente piorar as coisas.

O Jujutsu resolve quase tudo isso. Como regra geral, o resultado de qualquer comando jj pode ser revertido com jj undo, e o próprio undo pode ser desfeito com jj redo. Isso é possível porque o Jujutsu mantém, separado do log normal, um registro de cada operação que altera o repositório: o operation log. Cada entrada do operation log está ligada a um snapshot do repositório como ele ficou ao final daquela operação. Você pode restaurar os arquivos para esse estado, ou reverter só o efeito daquela operação, mantendo tudo o que veio depois.

Cada comando jj que uma IA executa durante uma longa sessão de tentativa e erro também vai parar no operation log. Quando algo dá errado, você pode repassar tudo o que a IA fez, identificar a causa e voltar ao estado logo antes de as coisas desandarem.

Além disso, ao contrário do hash de um commit do Git, que muda toda vez que você edita o commit, o change ID do Jujutsu continua o mesmo, não importa quantas vezes o change seja revisado. Você pode consultar o histórico de revisões de um change no evolution log e, com um pouco de garimpo, encontrar uma versão anterior e restaurar seu conteúdo. Usando a data e a hora ou o diff como referência, dá até para se recuperar de uma resolução de conflito malfeita de vários dias atrás e refazê-la.

Cada edição é salva no histórico conforme você trabalha. O operation log e o evolution log permitem encontrar onde as coisas deram errado e voltar a esse ponto. E se a própria recuperação der errado, jj undo e jj redo deixam você tentar de novo na mesma hora. É um nível de segurança que o Git simplesmente não oferece, e é exatamente por isso que, com o Jujutsu, consigo entregar o controle de versões a uma IA com mais tranquilidade, e com mais ousadia, do que jamais consegui com o Git.

Por que um histórico limpo importa mais na era da programação com IA

Outro comentário que se destacou no meu último post foi “não faço questão de manter o histórico limpo, então não vejo sentido no Jujutsu”. O raciocínio parece ser que, mesmo que o histórico esteja uma bagunça, basta pedir à IA para encontrar o que você precisa. Mas será que é assim mesmo? Eu diria que é o contrário: justamente porque, com a IA, escrevemos e lemos menos código, um histórico limpo importa mais do que nunca.

Os agentes de programação melhoraram tanto que muitos desenvolvedores hoje mal escrevem código e também não leem cada linha que a IA gera. Mesmo assim, eles continuam zelando pela qualidade do que vai para produção, seja pedindo a um agente com outro modelo que revise o trabalho, seja conferindo pessoalmente as partes críticas, como mudanças em estruturas de dados. Se você consegue rastrear direto no histórico o que mudou, por que e do que depende, tudo isso fica mais rápido e com menos erros. Justamente porque ninguém está revisando cada linha, seu histórico de commits precisa funcionar como o sumário do código , para que você encontre as partes que importam. Uma sequência de commits gigantes sem intenção clara obriga a IA a carregar contexto irrelevante toda vez, o que gasta tokens e pode prejudicar a qualidade do trabalho dela.

No início de cada sessão, um agente costuma olhar primeiro os diffs significativos mais recentes, antes do diretório de trabalho como um todo. Enfie “uma correção de bug + uma atualização de dependências + conteúdo sem relação + uma refatoração que não tem nada a ver” em um único commit, e o agente se confunde. Organize commits de tamanho razoável e com intenção clara, numa ordem que reflita a relação de causa e efeito, e até um prompt curto vai dar ao agente o contexto de que ele precisa para a próxima tarefa.

E mesmo que você quase não leia o código gerado pela IA durante o desenvolvimento, um incidente vai obrigar você a lê-lo com atenção. A primeira pergunta diante de uma queda em produção é “quando e onde entrou o código problemático?”. Quando cada minuto conta, um histórico de commits semanticamente coerentes ajuda você a localizar o problema rapidamente.

A programação com IA também criou um problema novo ao disparar a produtividade: os PRs ficam enormes → fica difícil revisá-los → PRs sem merge se acumulam à espera de revisão. Agora até equipes de poucas pessoas caem nesse ciclo. Gigantes de tecnologia como Google e Meta lidam com esse problema há mais de uma década, e a resposta delas tem sido “dividir os PRs em unidades pequenas que dependem umas das outras”. Suponha que você normalmente enviaria uma funcionalidade inteira como um único PR. Em vez disso, você cria quatro PRs: “1. alterações na camada de modelo”, “2. alterações nas tarefas agendadas”, “3. alterações na API do servidor” e “4. alterações no frontend web”. Depois, empilha esses PRs na ordem 1 → 2 → 3 → 4. Cada um pode ser revisado, aprovado e receber merge separadamente, mas um PR só pode receber merge depois que os PRs abaixo dele na pilha (no caso do 3, o 1 e o 2) já tiverem entrado. Essas empresas incorporaram esse fluxo às suas ferramentas e passaram a usá-lo no desenvolvimento do dia a dia.

PRs pequenos e com um papel lógico claro facilitam a vida de quem revisa, e fica mais fácil identificar quais você precisa revisar. As alterações no branch de um PR mais abaixo na pilha se propagam automaticamente para os branches acima dele, com o rebase feito pelas ferramentas. E, graças às dependências, você pode começar com segurança a próxima parte do trabalho enquanto o primeiro PR ainda espera revisão. É isso que se costuma chamar de stacked diffs ou stacked PRs. Graphite, GitButler, GitLab e outros vêm oferecendo suporte há anos. E, em julho de 2026, o GitHub finalmente lançou os stacked PRs em versão prévia pública. Com o maior player a bordo, tudo indica que a tendência vai ganhar força.

Entre a popularização dos monorepos e o impacto dos agentes de IA, a demanda por stacked PRs está crescendo não só nas grandes empresas, mas também nas pequenas e médias. Quando os stacked PRs passam a fazer parte do jeito de trabalhar de uma equipe, acertar as unidades do histórico e a ordem delas vira parte do trabalho de cada desenvolvedor. PRs em que antes cabia de tudo agora precisam ser divididos pelo papel lógico, com dependências entre eles. E o Jujutsu torna isso fácil e seguro.

Pense em dividir um commit gigante em unidades com sentido. É uma tarefa difícil, até para a IA. No Git, você provavelmente faria git reset HEAD^ para devolver o commit inteiro à working tree e depois repetiria o ciclo de adicionar ao índice e fazer commit, pedaço por pedaço. Se você errar no meio do caminho, recuperar-se significa descobrir exatamente até onde a divisão chegou e quais edições ficaram onde, o que já é uma dor de cabeça por si só. E se o commit que você quer dividir for antigo, prepare-se para a emoção de encadear rebases com o HEAD desanexado (detached HEAD). No Jujutsu, você passa os arquivos para jj split -m <description> e pronto. Se errar, desfaz e tenta de novo. Quando quem faz isso é uma IA, a divisão é por arquivo, mas uma pessoa operando o Jujutsu pode usar jj split -i para dividir de forma interativa, linha a linha, ou consultar o evolution log e dividir o trabalho na ordem em que ele foi realmente feito.

Transformar um branch de trabalho em uma cadeia de branches dependentes para um stacked PR dá muito trabalho no Git. No Jujutsu, basta ir colocando bookmarks, um depois do outro, em uma única linha do histórico. A documentação oficial do GitHub inclusive mostra, passo a passo, como montar a cadeia de branches de um stacked PR com o Jujutsu⁴. É bom ver essa afinidade reconhecida oficialmente.

O que é fácil para pessoas também é fácil para a IA

O Git foi projetado colocando as funcionalidades à frente de quem usa. O Jujutsu é um sistema de controle de versões criado para resolver os pontos fracos do Git⁵ e para manter a carga cognitiva das pessoas o mais baixa possível. E o que é fácil para a mente humana acaba sendo fácil para a IA também. Você nunca precisa se preocupar se uma edição já entrou no histórico, porque o estado do diretório de trabalho é o ponto atual do histórico. Um change mantém o mesmo ID não importa quantas vezes seja revisado, então ele nunca se perde durante longas rodadas de tentativa e erro. O operation log registra cada operação em ordem, então é fácil ver qual passo deu errado e restaurar a partir dali. E quando surge um conflito no meio de uma tarefa, o próprio estado em conflito é salvo no histórico, então você pode ir com calma e tentar resolvê-lo quantas vezes precisar. Cada uma dessas características é uma grande vantagem quando é a IA que está no comando.

O Jujutsu não está tão integrado às ferramentas dos agentes de IA quanto o Git. Mas é muito mais fácil para esses agentes entenderem como ele funciona, o que tende a tornar o trabalho deles mais estável e seguro. Mesmo que você entregue à IA o controle de versões junto com a programação, escolher o Jujutsu para essa tarefa faz todo o sentido.

Essa é a minha opinião, e também o argumento que desenvolvo no “Capítulo 1: Que tipo de ferramenta é o Jujutsu?” do meu livro, Juju-chu! — Comece seu fluxo de trabalho Jujutsu × IA com jj new. O capítulo desenvolve esse argumento ao explorar cada funcionalidade. O “Capítulo 3: Fluxo de trabalho Jujutsu × IA na prática” é um passo a passo prático de como realmente entregar a operação do Jujutsu ao Claude Code e ao Codex.

Juju-chu! — Comece seu fluxo de trabalho Jujutsu × IA com jj new

Um 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

Se este post despertou sua curiosidade pelo Jujutsu, dê uma olhada.

Footnotes

Para ser exata, sempre que qualquer comando jj é executado, o Jujutsu compara a cópia de trabalho com o estado mais recente do histórico. Se houver diferenças, ele tira um snapshot e o change ganha uma nova revisão. Se você usa uma interface gráfica do Jujutsu, ela normalmente tira um snapshot automaticamente sempre que você consulta o histórico nela. ↩
Um detalhe: um change sem descrição não pode ser enviado ao remoto com push. ↩
Veja Faça seu agente de programação usar Jujutsu em vez de Git. ↩
Usar outras ferramentas com solicitações de pull empilhadas - Documentos do GitHub ↩
Solving Git’s Pain Points with Jujutsu (with Martin von Zweigbergk) - YouTube ↩

15 anos de Git e depois Jujutsu: por que não consigo mais voltar

Yuka Ooka — Mon, 28 Sep 2026 00:00:00 +0000

2026: o primeiro VCS que escolhi de verdade

Olhando para trás, eu nunca cheguei a escolher um sistema de controle de versões (VCS). Usava o que a empresa onde eu trabalhava tivesse adotado. Na maioria dos meus empregos anteriores, usava-se Subversion em um servidor interno. Até que, em 2011, entrei em uma empresa que tinha adotado o GitHub, o que significava que todos os engenheiros precisavam usar Git. Foi aí que comecei a usar Git e GitHub para valer.

Vindo do Subversion, o Git me parecia pouco intuitivo e difícil de usar. O GitHub também trouxe uma nova exigência: deixar o histórico limpo para facilitar a revisão. Os comandos para isso eram inconsistentes e difíceis de memorizar, e cada um vinha com aquela pressão de saber que não dava para errar.

Com o tempo, aquela frustração foi amortecendo e eu aceitei que as coisas eram assim. Mesmo assim, continuava sem conseguir memorizar os comandos. Qualquer coisa um pouco mais complicada exigia uma busca no Google, e eu evitava tudo o que pudesse causar um conflito. Assim se passaram cinco anos, depois dez. Justo quando parecia que os quinze passariam do mesmo jeito, tudo mudou. Chegaram os agentes de IA para programação, como o Claude Code, e, quase sem eu perceber, a IA já escrevia mais código do que humanos. Alguns anos antes, eu não teria acreditado.

Dê instruções a uma IA e ela escreve o código num piscar de olhos. Com tudo andando tão rápido, o ritual trabalhoso de fazer add e depois commit no Git virou um verdadeiro gargalo. Se funcionava, eu fazia o commit por enquanto, mesmo sem ainda entender o código tão a fundo quanto o que eu mesma tinha escrito. E depois, inevitavelmente, queria mudar coisas. Perdia alterações importantes em algum ponto do inferno do rebase, ou desistia e empilhava commits de remendo por cima até o histórico virar uma bagunça. Isso passou a fazer parte do dia a dia.

Foi então que encontrei o Jujutsu. No Japão, por volta de janeiro de 2026, uma leva de artigos introdutórios circulou bastante, e a comunidade de desenvolvedores em geral começou a prestar atenção nele. Depois de ler alguns, achei que ele combinaria bem com a programação com IA e o experimentei em um projeto em que eu estava trabalhando. A filosofia de design e os comandos são tão diferentes dos do Git que, no começo, tive muita dificuldade para usá-lo. O que me impediu de desistir foi a simplicidade de trabalhar sem staging area e a tranquilidade de saber que qualquer operação podia ser desfeita. Depois de mais ou menos um mês, eu já conseguia usá-lo razoavelmente bem.

Desde então, gerencio todos os meus repositórios com o Jujutsu, e também escrevo tudo com ele, de posts de blog e documentação a manuscritos de livros (este post incluído, claro). Pensando bem, trocar o Git pelo Jujutsu foi a primeira vez que escolhi um VCS por conta própria. E, em algum momento, percebi que não conseguia mais voltar ao Git. Estas são, na minha visão, as razões pelas quais não tenho a menor vontade de voltar.

Razão 1: nunca preciso me perguntar se meu trabalho está salvo

O Git usa um modelo de três estados: working tree → índice → repositório local. Para registrar uma alteração no histórico, primeiro você a coloca em staging com git add e depois executa git commit. No Jujutsu, o estado da sua cópia de trabalho (working copy) já é, em si, um commit. Do ponto de vista do Jujutsu, não existe diferença entre o seu diretório de trabalho e o commit atual. Isso traz algumas vantagens práticas:

Você nunca precisa decidir quando salvar no histórico
Você não precisa de nada parecido com git stash ao trocar de tarefa
É muito improvável que você perca trabalho em andamento

Controlar quais arquivos ainda não estão em staging ou ainda não entraram em um commit é uma carga cognitiva que não tem nada a ver com o trabalho de desenvolvimento em si. O mesmo vale para guardar e recuperar stashes quando algo inesperado interrompe você. O Jujutsu reduz esses custos a quase zero.

Na programação com IA, com a configuração certa, basta pedir a um agente “crie a funcionalidade X”. O trabalho vai sendo registrado em um único commit à medida que avança, e o agente o finaliza com uma mensagem como “feat: X”. No fluxo normal, você não precisa cuidar do histórico em nenhum momento.

Você também quase nunca passa pela situação de ver git reset, git clean ou um comando do shell apagar arquivos que não dá mais para recuperar. Eu mesma já tive arquivos apagados por um agente de IA sem conseguir recuperá-los e, mesmo hoje, com modelos supostamente muito melhores do que antes, ainda vejo relatos assim de vez em quando. O Jujutsu faz commit da cópia de trabalho conforme você trabalha¹, então, na maioria dos casos, qualquer coisa apagada por engano pode ser recuperada do histórico.

Se eu fosse obrigada a voltar ao Git, teria que voltar a pensar em salvar, e estaria sempre a um comando errado de perder o trabalho em andamento. Só de imaginar, já fico cansada. O Jujutsu reduz a carga cognitiva do controle de versões e me dá tranquilidade.

Razão 2: experimentar fica muito mais barato

Agora que um agente de IA consegue construir em instantes o que eu pedir, faço muito mais tentativa e erro: construir algo, ficar com o resultado se estiver bom e jogar fora e recomeçar se não estiver. Fazer isso no Git logo fica complicado. Se você experimenta na working tree sem fazer commit, fica sem saída quando descarta algo e depois decide que queria aquilo. Se quiser guardar no histórico, precisa de branches, e criá-los, alternar entre eles, fazer merge e apagá-los dá tanto trabalho que experimentar começa a dar preguiça.

E como o Jujutsu resolve isso? A unidade básica do histórico no Jujutsu, mais ou menos equivalente a um commit do Git, é o change. Quando o Jujutsu detecta edições na cópia de trabalho, ele atualiza automaticamente o change atual e também guarda as versões anteriores. Basta experimentar dentro de um change. Crie um novo com jj new e teste o que quiser. Se gostar do resultado, dê a ele uma descrição (mais ou menos, uma mensagem de commit). Se não gostar, descarte-o com jj abandon. Se depois quiser recuperá-lo, jj operation revert <operation ID> desfaz essa operação² e, se você acabou de descartá-lo, um único jj undo o traz de volta.

O Jujutsu também permite criar ramificações a partir de qualquer ponto do histórico sem dar nome a nada. Basta passar o ID do change pai para jj new. Para comparar abordagens diferentes para a mesma tarefa, crie vários desses changes irmãos e alterne entre eles com jj edit <change ID>. Dê uma descrição ao que quiser manter e faça jj abandon do resto. Só isso.

Como o change, a unidade básica do histórico do Jujutsu, também serve de área de testes, experimentar passa a fazer parte do fluxo de trabalho normal. Não é preciso fazer merge. E como, ao começar um experimento, você não sabe se ele vai dar certo, também não precisa dar nome a ele de antemão.

Se eu fosse obrigada a voltar ao Git, com certeza teria mais resistência a experimentar. Já me vejo deixando de criar o branch pelo trabalho que dá, experimentando na working tree, jogando algo fora, querendo recuperar e me arrependendo.

Razão 3: reescrever o histórico é simples e intuitivo

Quando eu mesma escrevia o código, eu o conhecia de trás para a frente, então meus commits eram sólidos e raramente eu precisava voltar a eles. Mas quase ninguém lê cada linha que uma IA gera e a entende tão bem quanto o próprio código antes de fazer commit. Por isso, hoje me pego querendo alterar commits supostamente prontos com muito mais frequência do que antes.

Suponha que você queira incluir uma alteração em src/styles/global.css no commit de três posições atrás. Como isso fica no Git e no Jujutsu? Há duas formas de fazer isso: editar diretamente o commit em questão ou fazer a alteração por cima e incorporá-la (squash) a esse commit. Aqui vou comparar a primeira.

Vamos começar pelo Git. Não dá para fazer isso com alterações sem commit no caminho, então, se houver alguma, primeiro você precisa guardá-las com git stash -u. Depois:

git rebase -i HEAD~4

No editor que se abre, troque pick por edit na linha do commit em questão e salve.

- pick bbbbbbb Mensagem do commit B
+ edit bbbbbbb Mensagem do commit B
  pick ccccccc Mensagem do commit C
  pick ddddddd Mensagem do commit D
  pick eeeeeee Mensagem do commit E

Agora sua working tree está no commit B. Edite src/styles/global.css e faça o commit.

git add src/styles/global.css
git commit --amend --no-edit

Mas ainda não acabou. Os commits seguintes ainda precisam ser reaplicados sobre essa edição. Execute git rebase --continue e reze para não haver conflito. Se houver, o rebase para, e você precisa corrigir os arquivos, fazer git add e executar git rebase --continue de novo, quantas vezes forem necessárias. Se você se perder no meio do caminho, git rebase --abort leva você de volta à estaca zero. É cansativo.

Agora, a mesma coisa no Jujutsu. jj edit @--- move a cópia de trabalho para o change de três posições atrás. Edite src/styles/global.css. O Jujutsu faz automaticamente o rebase dos changes descendentes sobre ele, então, se não houver conflitos, pronto. Mesmo que surja um conflito, o rebase automático termina sem parar. Basta ir com jj edit até o change em conflito e corrigi-lo ali, e o rebase automático é executado de novo.

Ter menos passos é um bônus, mas a grande vantagem é que tudo fica muito mais intuitivo. Você vai até o ponto do histórico que interessa e edita os arquivos. O Jujutsu cuida do rebase por conta própria, então você mal percebe que ele está acontecendo. No Git, por algum motivo, o rebase é o protagonista. Você começa com git rebase e termina com git rebase. É contraintuitivo, e os passos intermediários são tão trabalhosos que nunca consegui memorizá-los.

Se eu fosse obrigada a voltar ao Git, provavelmente evitaria reescrever o histórico sempre que pudesse, por causa do trabalho que dá. Commits de remendo se acumulariam, ou alterações sem relação acabariam enfiadas em qualquer commit que estivesse à mão, e meu histórico ficaria muito mais difícil de ler.

Razão 4: vejo o histórico como um grafo, não só como uma linha do tempo

Vamos começar comparando a saída do comando de log de cada ferramenta. A primeira é do git log; a segunda, do jj log. Por padrão, o Jujutsu oculta a maioria dos changes imutáveis, então passei -r :: para remover essa limitação.

O log do Git mostra o que aconteceu no seu branch atual, em ordem e em linha reta, como a cronologia de um livro de história. O log do Jujutsu oferece uma visão panorâmica de todo o histórico, desenha as ramificações com arte ASCII e concentra mais informação. Num relance, você absorve muito mais.

O que acontece quando você vai para um ponto passado do histórico também é diferente. Execute git checkout <commit ID> no Git, e o git log deixa de mostrar o que vem depois desse ponto. Execute jj edit <change ID> no Jujutsu, e o log continua como estava. Só a marca @, que representa o commit da cópia de trabalho, se move para o nó desse change.

Essas diferenças na aparência e no comportamento do log dizem muito sobre a filosofia de design de cada ferramenta. No Git, em princípio, espera-se que você esteja em algum branch com nome enquanto trabalha, e você está sempre sendo empurrado para a ponta dessa única linha do histórico. Talvez seja por isso que o log padrão nem se dá ao trabalho de mostrar onde você está no histórico como um todo nem o que acontece fora dessa linha³.

O Jujutsu não tem nada que corresponda aos branches com nome do Git⁴. Você pode ir livremente para qualquer nó editável do histórico, esteja ele na linha que estiver. É por isso que um grafo do histórico completo é tão útil.

Reescrever o histórico no Jujutsu é fácil, em boa parte, graças a esse log denso e legível. É como trabalhar em um programa de edição de vídeo com uma linha do tempo de várias trilhas à sua frente. Em comparação, editar o histórico no Git parece cortar filme analógico com tesoura e colar os pedaços de volta.

O git log também consegue desenhar uma árvore em arte ASCII se você passar --graph, embora não seja tão legível quanto a do Jujutsu. Mas ver o grafo não permite editar entre branches de forma intuitiva e segura como no Jujutsu, então, mesmo que eu voltasse ao Git, quase não o usaria.

O lugar do Git hoje

Já faz mais de seis meses que migrei totalmente para o Jujutsu, mas, na verdade, não parei de usar o Git. A camada de armazenamento do Jujutsu é plugável, e ele pode usar um repositório Git como backend. Quando você inicializa um repositório com o Jujutsu, por padrão obtém um colocated workspace, com .git/ e .jj/ lado a lado na raiz do projeto. Continuo usando um repositório Git; só deixei de usar a interface do Git para trabalhar com ele. O comando git continua funcionando, se você precisar.

Graças a essa compatibilidade, ninguém ao seu redor vai saber que você usa o Jujutsu, a menos que você conte. Em uma equipe que usa GitHub ou GitLab, é perfeitamente possível que alguém esteja usando o Jujutsu discretamente esse tempo todo. No dia a dia, praticamente as únicas vezes em que penso no Git são quando preparo um repositório com jj git init ou jj git clone e, a partir daí, quando sincronizo com o remoto usando jj git fetch e jj git push.

Comecei a usar o Git por causa do GitHub e troquei pelo Jujutsu quando mergulhei de vez na programação com IA. Agora não tem mais volta. Depois de tantos anos acostumada ao Git, alguns jeitos do Jujutsu me pareceram estranhos no começo. Mas, olhando para a história do controle de versões, muitas vezes o estranho era o Git, e hoje o Jujutsu me parece mais natural na maioria das situações.

Ainda assim, o Jujutsu continua sendo pouco conhecido, e me frustra que uma ferramenta tão boa não tenha mais visibilidade. O problema é que ele é compatível com o Git, mas se baseia em um modelo mental muito diferente. Se você o experimentar com a cabeça no Git, guiando-se por uma tabela de equivalência entre comandos do Git e do jj, mal vai notar as vantagens. Por isso escrevi um guia de Jujutsu para iniciantes pensado para você não travar no caminho , centrado em ajudar você a adotar esse novo modelo mental.

Juju-chu! — Comece seu fluxo de trabalho Jujutsu × IA com jj new

Um 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

Ele se chama Juju-chu! — Comece seu fluxo de trabalho Jujutsu × IA com jj new. O livro tem uma capa no estilo light novel e um visual divertido, mas o conteúdo é sério. O livro orienta você passo a passo, desde os primeiros contatos com o Jujutsu até você conseguir usá-lo com confiança. Se este post despertou sua curiosidade pelo Jujutsu, dê uma olhada. Na página, você encontra uma amostra que pode ler diretamente no navegador.

Footnotes

Para ser exata, sempre que qualquer comando jj é executado, o Jujutsu verifica se há diferenças entre a cópia de trabalho e o estado mais recente do histórico e, se houver, faz o commit. Agentes de IA instruídos a usar o Jujutsu costumam conferir o próprio trabalho com jj status ou um comando parecido nas pausas naturais de uma tarefa, e é nesse momento que o commit acontece. ↩
Além do log normal, o Jujutsu mantém um registro de operações com cada operação realizada no repositório. Cada entrada tem um ID de operação, que você pode usar para reverter essa operação ou restaurar os arquivos como estavam logo depois dela. ↩
Refiro-me ao comportamento padrão. Com --all, você vê todos os branches do seu repositório local e os commits alcançáveis a partir deles. ↩
Os bookmarks do Jujutsu são tratados como branches ao trabalhar com o Git, mas, conceitualmente, são outra coisa. ↩