jj, ou o git de forma diferente

Conheci há umas semanas o jujutsu (jj), um cli que apresenta uma alternativa para a operação do git. Na verdade, dizer que é um cli diminui muito o que esta ferramenta é, e faz.

Ao contrário do git, que trabalha com commits e branches, de forma isoladas, o conceito principal é de trabalhar com checkpoints de um estado atual.

Se estamos trabalhando em um projeto qualquer, não apenas de software, pensamos em incrementos. Algo começa, e a cada ciclo, fazemos alterações. Usualmente, definimos o que será feito, fazemos, e finalmente encerramos este ciclo, começando outro. Todas as alterações feitas são parte deste ciclo.

O jj adota esta ideia como base para o controle de versões de código.

Usualmente, o processo com o git passa por criar um branch, fazer todas as alterações nesse branch, e posteriormente unir este branch ao principal. Criamos um espaço separado para o código sendo construído.

Usando o jj, o processo muda um pouco. Estamos sempre trabalhando em um estado atual de código, e quanto terminamos, criamos outro. E assim por diante. Sempre que terminamos uma alteração, temos um novo changeset que identifica conjunto de alterações agrupados, e o histórico é criado em uma sucessão de revsets.

Como estamos sempre trabalhando com o estado atual do código, não existe staging area nem a necessidade de adicionar os arquivos para um commit. Partimos do princípio que tudo tem que ser adicionado àquele revset, e ao criar um novo changeset, automaticamente temos o estado do changeset atual salvo.

Se ficou complexo, vamos ver um exemplo.

A lista de comandos usados abaixo está aqui

Esse exemplo é simples, apenas para mostrar como a ideia de changeset funciona. Temos muito mais possibilidades, como criar changesets baseados em um changeset anterior, publicar changesets como branches, fazer rebases, e assim por diante.

Existe um guia muito bom sobre isso em https://steveklabnik.github.io/jujutsu-tutorial/, que é ótimo para aprender mais sobre esta ferramenta.

E, interessante saber: tem suporte a tudo o que o git faz. Tudo mesmo. Mas às vezes de uma forma diferente. Dá pra trabalhar com repositórios remotos, diferentes changesets a partir de um inicial e posterior rebase, e assim por diante.

Já conheciam a ferramenta? Se interessaram, e querem saber mais? Se sim, deixa uma mensagem aqui, e eu vou respondendo, e quem sabe até fazer uma continuação.

Experiência pessoal: estou usando em projetos pessoais, de código e de escrita. A principal vantagem tem sido, pra mim, a possibilidade de pensar o processo de gerenciamento de alterações de forma mais natural, adequado com a forma de ver a organização de projetos, onde definimos o que vamos fazer, fazemos, testamos, e fechamos, iniciando uma nova parte. Na minha visão, é o futuro do git. E isso não é só minha opinião.

Comments

[Eduardo Klosowski]

Essa ideia de uma branch por feature, depois abre o PR usada no git não é a única opção. Já ouvi de empresas que todo mundo trabalha fazendo commits direto no main, e se demorar mais de 5 ou 10 minutos para fazer um commit, deveria jogar fora, atualizar a main e começar a alteração de novo. Também fiquei pensando como seria o fluxo no jj para abrir um PR e trabalhar na próxima feature, seja ela dependente desse último PR ou não. Isso imaginando um fluxo com revisão de código.

Uma coisa que não gostei do jj é justamente ele pegar todas as alterações. Normalmente eu começo a fazer uma tarefa, e vou descobrindo que precisa alterar outros arquivos antes. No git eu posso simplesmente ir lá, fazer essas alterações, selecionar e fazer um commit apenas delas, e voltar ao que estava fazendo. Pelo que eu entendi do jj teria que desfazer o que já foi feito, ou mover para outro lugar, implementar a dependência que não estava clara antes, e depois voltar as alterações para o que eu estava antes.

Outra coisa que não gostei é da verbosidade para alguns comandos, no git eu posso fazer git log --all, já no jj o equivalente que vi seria jj log -r 'all()'.