Se você já perdeu tempo com essa sequência: ...só pra descobrir depois que esqueceu o que tinha no stash, ou que o / da outra branch estava desatualizado — este artigo é pra você.
O problema Um repositório Git tradicional tem uma única pasta de trabalho ligada a uma branch por vez.
Trocar de branch significa trocar todo o conteúdo dessa pasta.
Isso funciona bem quando você faz uma coisa de cada vez, mas quebra assim que você precisa: Revisar um PR urgente enquanto está no meio de uma feature grande Rodar testes de uma branch enquanto edita outra Manter ambientes de dependências diferentes (versões de libs, ) para features distintas sem reinstalar tudo a cada troca A saída mais comum é o , mas ele é frágil: some da vista, acumula, e é fácil esquecer o que tinha ali dentro.
A solução: O permite ter várias pastas de trabalho simultâneas, cada uma vinculada a uma branch diferente, todas compartilhando o mesmo histórico de commits (o ).
Pense em uma biblioteca central (o histórico do repositório) com várias mesas de leitura (as worktrees), cada uma com um livro diferente aberto.
Você não precisa fechar um livro pra abrir outro.
O que é compartilhado, o que é separado Compartilhado entre worktrees Separado por worktree Histórico de commits Arquivos da working directory Objetos do Git (blobs, trees) Arquivos não versionados (, , ) Configuração do repositório Saída do Um commit feito em uma worktree aparece imediatamente no das outras — mas os arquivos físicos de cada pasta continuam independentes.
Colocando em prática Criando uma worktree com branch nova Isso cria a pasta , já com uma branch nova criada a partir do commit atual.
Criando uma worktree para uma branch que já existe Útil quando a branch já veio de um colega ou de um PR aberto.
Listando as worktrees ativas Saída parecida com: Removendo uma worktree depois do merge Se a pasta tiver mudanças não commitadas, o Git avisa e pede .
Estrutura de pastas sugerida Cada pasta pode ter seu próprio ambiente virtual, seu próprio servidor rodando em uma porta diferente, sua própria instância do editor aberta — sem um interferir no outro.
Convenção de nomes ligada ao board Se seu time usa um board tipo Jira/Linear, vale manter o ID do card no nome da branch (e da worktree): Isso facilita rastrear no PR, no CI e em qualquer extração de métricas de fluxo (lead time, deployment frequency) que você faça a partir do histórico de branches.
Dicas práticas
1.
Evite worktrees de vida muito longa.
O worktree resolve o problema de contexto simultâneo, não o de branches gigantes.
Combine com features pequenas e merges frequentes — se uma feature for demorar semanas, considere feature flags em vez de manter a branch (e a worktree) viva por muito tempo.
2.
Cuidado com portas e serviços locais.
Se cada worktree sobe um servidor de desenvolvimento, defina portas diferentes por ambiente ( com , por exemplo) pra evitar conflito.
- continua valendo por pasta.
Arquivos como , , não são compartilhados automaticamente — cada worktree precisa da própria cópia (ou de um / local).
4.
Worktrees podem viver fora do diretório do repo.
Não precisam ficar como subpastas; o exemplo usa só por convenção de organização.
Por que isso importa A alternativa mais comum ao worktree — múltiplos clones separados do mesmo repositório — resolve o problema de paralelismo, mas duplica o histórico completo em disco e obriga a sincronizar remotes manualmente entre os clones.
O worktree resolve o mesmo problema mantendo um único como fonte de verdade, com o custo de espaço em disco apenas dos arquivos de trabalho, não do histórico inteiro.
Se seu fluxo de trabalho envolve alternar entre features, revisar PRs no meio de outra tarefa, ou manter hotfixes prontos pra aplicar sem abandonar o que está em andamento, o provavelmente vai economizar mais tempo do que qualquer alias de que você já criou.
Já usa no seu fluxo?
Como você organiza as pastas e os ambientes de cada worktree?
Comenta aí.