git worktree: dois ramos abertos sem clonar duas vezes

Está-se a meio de uma alteração e chega uma correção urgente noutro ramo. As respostas habituais são três: guardar na pilha, fazer um commit a meio, ou clonar o repositório outra vez. Há uma quarta, e resolve melhor do que as três.

git worktree add ../projeto-correcao main

Uma segunda pasta de trabalho, com o main em cima, a partilhar o mesmo repositório. Dois ramos abertos ao mesmo tempo, um histórico só.

1. O que dá e a pilha não dá

Os dois estados ficam em disco em simultâneo. É isto, e quase nunca se diz: a pasta original mantém o que lá estava — as dependências instaladas, o resultado da compilação, a cache do bundler, o servidor de desenvolvimento a correr.

Guardar na pilha limpa a árvore, e voltar atrás significa reinstalar, recompilar e reaquecer tudo. Numa aplicação que leve dois minutos a arrancar, a diferença entre as duas abordagens é o dia inteiro.

2. O que dá e um clone novo não dá

Um só armazenamento de objetos: não se duplica o histórico em disco, que num repositório antigo é a maior parte do peso. As referências e os remotos são os mesmos, portanto um fetch serve as duas pastas. E não há a dúvida de saber em qual das cópias é que se estava a trabalhar.

3. As regras

git worktree list
git worktree remove ../projeto-correcao
git worktree prune

O mesmo ramo não pode estar em duas pastas ao mesmo tempo, e o Git recusa. Parece uma limitação e é uma salvaguarda: dois sítios a escrever no mesmo ramo é exactamente o conflito que ninguém quer depurar.

Apagar a pasta à mão funciona e deixa a entrada registada; o prune limpa as que já não existem.

4. A surpresa da primeira vez

O que o Git não segue não é partilhado. A pasta nova nasce sem node_modules e sem .env — porque ambos estão, com razão, fora do controlo de versões.

Portanto cada pasta de trabalho precisa da sua instalação e da sua configuração local. Não é um defeito, é a consequência directa de o .gitignore existir, e é o que faz a maioria das pessoas desistir ao primeiro ensaio por achar que alguma coisa correu mal.

5. Onde ganha de verdade

• Revisar o trabalho de outra pessoa com a aplicação dela a correr, sem parar a nossa.

• Comparar comportamento entre dois ramos ao vivo, lado a lado, em vez de alternar e confiar na memória.

• Correr os testes do main enquanto se continua a escrever no ramo.

• Procurar o commit que partiu tudo numa pasta à parte, sem desarrumar a árvore em que se estava — o bisect move a cópia de trabalho muitas vezes, e fazê-lo noutra pasta tira-lhe o incómodo todo.

6. Quando não vale a pena

Para corrigir uma linha num ficheiro, a pilha dá menos trabalho. A pasta nova só se paga quando os dois estados precisam de poder correr — e é essa a pergunta que decide entre as duas: preciso de ter isto a funcionar, ou só de o ter guardado?

O resumo

Uma pasta por ramo, um histórico só. Vale pelo que fica intacto na pasta de origem, e não pela comodidade de trocar de ramo. Cada pasta precisa das suas dependências e do seu .env. E escolhe-se contra a pilha por uma pergunta: os dois lados têm de estar a correr?