jj, ou o git de forma diferente

oerickmuller — Tue, 02 Sep 2025 20:52:05 +0000

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.

Exportar markdown para docx usando o pandoc

oerickmuller — Wed, 13 Aug 2025 18:04:26 +0000

Versão em vídeo: https://www.youtube.com/watch?v=R4kf6lqkSl8

Se você está trabalhando com documentações versionadas, uma das melhores saídas é o conjunto markdown + git. Assim, consegue controlar as edições de forma simples, e usando um mecanismo de formatação muito robusto.

E quando o time que não usa markdown precisa de acesso a estes documentos, e exige que seja enviado em formato doc ou docx, como fazer? É nesse momento que o pandoc entra em ação.

O pandoc é uma ferramenta de conversão de arquivos de texto para diferentes formatos, que funciona de forma extremamente simples. Como o exemplo abaixo:

pandoc restricoes.md -o restricoes.pdf

Convertemos o documento restricoes.md para o formato pdf de jeito rápido e simples.

Porém, quando usamos a conversão para o formato doc/docx, sempre nos deparamos com o problema da formatação. Isso porque não conseguimos, no markdown, informar qual a formatação aplicar para cada elemento, de forma padronizada.

Mas até para isso a solução é simples:

Primeiro, você gera o documento de referência da formatação, com:

pandoc --print-default-data-file  reference.docx > custom-reference.docx

Onde o reference.docx não precisa existir localmente, ele é apenas a referência que o pandoc vai usar.

Depois, você abre o arquivo de referência e altera as formatações como desejar. Neste ponto, é importante não alterar o conteúdo do arquivo, apenas a formatação dos itens. Pode mudar também o tamanho da página, da margem, e assim por diante.

Terminado isso, só efetuar a conversão do arquivo como necessário, informando o arquivo de referência no momento de fazer a conversão. Voltando no exemplo anterior, do arquivo restricoes.md:

pandoc restricoes.md -o restricoes.docx --reference-doc=custom-reference.docx

Essa ideia é interessante porque pode ser integrada, por exemplo, em um pipeline de geração de documentação sob demanda.

DEV Community: oerickmuller

jj, ou o git de forma diferente

Exportar markdown para docx usando o pandoc