Você está trabalhando em uma feature quando um colega pede para você revisar o pull request dele. Dá para dar um stash, trocar de branch e torcer para lembrar de onde parou. Ou pode fazer um commit pela metade só para não perder o que estava fazendo. E ainda tem o hotfix de emergência: produção caiu, e você está no meio de um refactor que mexe em metade do código. Cada troca de contexto dessa custa 10–15 minutos de preparação e quebra totalmente o foco.
Git worktree resolve isso permitindo que você dê checkout em várias branches ao mesmo tempo, cada uma em um diretório separado. Em vez de fazer stash ou commitar trabalho incompleto, você simplesmente dá cd para outro diretório onde outra branch já está em checkout. Trabalhe no hotfix, faça o deploy e depois dê cd de volta para sua feature exatamente como você deixou.
Neste tutorial, vou te mostrar como criar e gerenciar worktrees, evitar armadilhas comuns e integrar isso ao seu fluxo de trabalho diário. Você já deve entender branches e commits no Git e operações básicas de linha de comando. Se quiser revisar os fundamentos de Git antes, recomendo o tutorial Introduction to Git da DataCamp para cobrir o essencial.
O que é Git worktree?
Git worktree é um recurso nativo que cria diretórios de trabalho adicionais vinculados ao mesmo repositório. Seu diretório de trabalho principal é a worktree primária, e cada worktree extra que você cria ganha seu próprio diretório com sua própria branch em checkout. Todas essas worktrees se conectam ao mesmo repositório .git.
Essa arquitetura compartilhada significa que os commits feitos em qualquer worktree aparecem imediatamente no banco de dados do Git, acessível por todas as outras worktrees. Os arquivos em si ficam independentes — editar train.py em uma worktree só afeta aquele diretório até você commitar as mudanças.
Por que não usar terminais diferentes?
Você não consegue abrir vários terminais no mesmo diretório e trabalhar em branches diferentes ao mesmo tempo. O Git só permite uma branch em checkout por diretório. Quando você roda git checkout feature-b em um terminal, os arquivos mudam para todos os terminais apontando para aquele diretório.
Git worktree resolve isso dando a cada branch seu próprio diretório. Cada diretório é totalmente independente, com seus próprios arquivos, processos em execução e artefatos de build. Trocar entre branches vira cd ../outro-diretorio em vez de git checkout outra-branch.
Pré-requisitos do Git worktree
Antes de usar git worktree, confira seu ambiente:
Git 2.5 ou superior: Rode git --version para verificar. Git worktree saiu em 2015, então a maioria das instalações já tem
Repositório Git existente: Você precisa de um repositório com pelo menos uma branch
Familiaridade com terminal: Todas as operações de worktree acontecem no terminal
Git worktree é ótimo quando trocar de branch interromperia seu trabalho atual:
Code reviews: teste as mudanças do colega sem fazer stash da sua feature
Hotfixes de emergência: corrija bugs em produção sem mexer no seu refactor
Desenvolvimento em paralelo: trabalhe em duas features independentes sem ficar trocando de branch
Processos longos: dispare uma suíte de testes de 30 minutos e continue codando em outra worktree
Evite para tarefas rápidas (menos de 10 minutos) em que git checkout é mais simples, ou quando você está focado em uma única atividade sem interrupções previstas.
Criando sua primeira worktree
A melhor forma de entender git worktree é criar uma e ver na prática. Vamos passar pelos comandos básicos, explorar a estrutura que o Git cria e observar como as mudanças fluem entre worktrees.
Configurando um repositório de exemplo
Antes de mergulhar em worktrees, você precisa de um repositório Git para usar. Se você já tem um projeto Python com várias branches, pule para a próxima seção. Caso contrário, vamos criar rapidamente um pipeline de ML simples:
mkdir ml-pipeline
cd ml-pipeline
git initTecnologia
Crie um README e um script Python:
echo"# ML Pipeline"> README.md
echo"def load_data():"> train.py
echo" print('Loading training data...')">> train.pyTecnologia
Isso cria um novo diretório chamado ml-pipeline-preprocessing um nível acima do local atual, dá checkout na branch feature-preprocessing lá e vincula ao seu repositório existente.
O Git confirma a criação:
Preparing worktree (checking out 'feature-preprocessing')
HEAD is now at 0a7f986 Initial commitTecnologia
Para trabalho novo, crie a branch e a worktree de uma vez:
A primeira linha mostra sua worktree principal — o diretório original contendo a pasta .git. A segunda linha mostra a worktree vinculada. Ambas exibem o hash do commit atual e a branch em checkout.
Cada diretório de worktree funciona como um repositório Git completo. Você pode navegar até ele, editar arquivos, rodar git status e fazer commits. Worktrees vinculadas não contêm um diretório .git completo — em vez disso, têm um arquivo .git que aponta para o repositório principal. Dentro da pasta .git principal, a pasta worktrees armazena metadados de cada worktree vinculada.
Trabalhando em uma worktree
Navegue até a worktree feature-preprocessing e faça um commit:
~/projects/
ml-pipeline/ [main] - seu trabalho de sempre
ml-pipeline-metrics/ [feature-custom-metrics]
ml-pipeline-loader/ [feature-streaming-loader]Tecnologia
Rode as duas features em paralelo — cada uma no seu terminal:
Cada linha mostra o caminho do diretório, o hash do commit atual e a branch em checkout. A primeira entrada é sempre sua worktree principal (a que contém a pasta .git), e as demais são worktrees vinculadas.
Para scripts ou navegação rápida, extraia apenas os caminhos:
Essa estrutura mantém tudo no mesmo lugar e torna os caminhos previsíveis. O padrão nomedoprojeto-nomedabranch diz exatamente o que cada diretório contém.
Alguns preferem uma pasta dedicada:
~/projects/
ml-pipeline/ # worktree principal
ml-pipeline-worktrees/
feature-auth/
hotfix-login/Tecnologia
Escolha uma abordagem e use com consistência. Nomes descritivos como ml-pipeline-user-authentication tornam os diretórios autoexplicativos, enquanto genéricos como ml-pipeline-temp ou ml-pipeline-2 te obrigam a checar o conteúdo. Trate worktrees como temporárias — crie para uma tarefa específica e remova quando terminar.
Armadilhas comuns
Mesma branch em múltiplas worktrees
O Git impede dar checkout da mesma branch em duas worktrees:
fatal: 'main' is already used by worktree at '/Users/you/projects/ml-pipeline'Tecnologia
Essa proteção existe porque você poderia fazer commits conflitantes. Se precisar do mesmo código em dois lugares, crie uma nova branch.
Worktrees esquecidas e espaço em disco
Cada worktree fica no seu disco até você removê-la explicitamente. Worktrees antigas se acumulam; projetos podem juntar 15+ worktrees esquecidas, consumindo gigabytes.
Cada worktree contém uma cópia completa dos arquivos do repositório. Um repositório de 500 MB com 5 worktrees consome 2,5 GB. Remova worktrees quando acabar:
git worktree list
git worktree remove ../ml-pipeline-old-featureTecnologia
Aninhar worktrees
Não crie uma worktree dentro do diretório de outra worktree. O Git até permite, mas isso confunde a estrutura de diretórios e torna a limpeza sujeita a erros.
Otimização do fluxo
Aliases no shell economizam tempo se você cria worktrees com frequência:
O ${PWD##*/} extrai o nome do diretório atual. Rodar wt feature-logging a partir de ml-pipeline cria ml-pipeline-feature-logging, navega para lá e configura um ambiente virtual Python com as dependências.
Adapte para sua linguagem: substitua a configuração de Python por bundle install para Ruby, cargo build para Rust, ou npm install para Node.js.
Seu editor ou IDE funciona com worktrees sem configuração especial. Cada worktree é só um diretório, então abra como qualquer pasta de projeto. A maioria dos editores modernos permite abrir múltiplas raízes de projeto ao mesmo tempo — você pode ter três worktrees na mesma janela e alternar entre elas na barra lateral.
Worktrees avançadas: desenvolvimento paralelo com apoio de IA
Se você usa assistentes de código com IA, worktrees liberam um fluxo paralelo poderoso. Essa abordagem ganhou força entre devs e times em 2024–2025.
Abra um painel de terminal para cada worktree e inicie seu assistente de IA:
# Pane 1cd ~/projects/ml-pipeline-logging
claude
# Pane 2cd ~/projects/ml-pipeline-optim
claude
# Pane 3cd ~/projects/ml-pipeline-bugfix
claudeTecnologia
Cada instância da IA trabalha em uma feature diferente sem interferência. Times relatam concluir trabalho em horas que antes levavam dias. Por exemplo, a incident.io roda 4–5 agentes do Claude Code em paralelo usando esse padrão. Em um caso, o Claude estimou uma melhoria de UI em 2 horas, mas terminou em 10 minutos.
Pontos de atenção:
Consumo de tokens: múltiplas sessões de IA usam mais créditos de API e podem atingir limites de taxa
Overhead de setup: cada worktree precisa do seu próprio ambiente e dependências
Carga cognitiva: gerenciar várias conversas em tarefas diferentes
Funciona bem para features grandes e independentes (30+ minutos cada), que não mexem nos mesmos arquivos, e quando você tem cota de API suficiente. Evite para correções rápidas, features muito acopladas ou quando estiver próximo dos limites de taxa da API.
Conclusão
Lembra do cenário do início — um colega precisa de review no PR enquanto você está no meio de uma feature. Agora você sabe a solução: git worktree add ../ml-pipeline-review pr/branch-name e depois cd para começar a revisar. Sua feature fica intocada. Sem stash, sem commit pela metade, sem esforço mental para reconstruir o contexto quando voltar. Dois diretórios, duas branches, zero atrito.
Git worktree não adiciona complexidade ao seu fluxo — ele remove. Cada worktree é só um diretório com uma branch em checkout. Mas essa simplicidade libera algo poderoso: a capacidade de alternar de contexto instantaneamente entre tarefas sem a carga cognitiva de fazer stash, dar checkout e reconstruir seu modelo mental.
Quando você precisar integrar worktrees a fluxos colaborativos como pull requests e code reviews, a trilha de habilidades GitHub Foundations da DataCamp cobre as práticas essenciais para trabalhar bem em times distribuídos.
FAQs sobre Git worktree
Posso usar Git worktrees com GitHub Desktop, VS Code ou outras ferramentas GUI?⌄
Sim. As worktrees aparecem para editores e GUIs de Git como pastas normais de projeto. Você pode abrir cada worktree como um projeto separado, e a maioria das ferramentas — incluindo VS Code, IntelliJ e GitHub Desktop — lida com elas sem qualquer configuração especial.
Como Git worktrees interagem com remotos como origin?⌄
Todas as worktrees compartilham o mesmo diretório .git, então também compartilham a configuração de remotos e o histórico de fetch. Você não precisa rodar git fetch em cada worktree — fazer fetch em uma atualiza os remotos para todas. O rastreamento de branches funciona exatamente como em um setup com uma única worktree.
O que acontece se eu apagar um diretório de worktree manualmente em vez de usar git worktree remove?⌄
O Git ainda vai achar que a worktree existe e marcá-la como “prunable”. Você não quebra o repositório, mas os comandos do Git podem exibir avisos. Rode git worktree prune para limpar a entrada obsoleta e remover com segurança os metadados órfãos.
Git worktrees são seguras para monorepos grandes ou sistemas de build como Bazel, Pants ou Nx?⌄
Sim, mas os artefatos de build podem multiplicar rápido. Cada worktree tem seu próprio diretório de trabalho, então caches, ambientes virtuais e saídas de build são duplicados. Em monorepos, é comum configurar as ferramentas de build para armazenar caches fora da worktree e evitar uso excessivo de disco.
Posso usar Git worktrees com submodules ou sparse checkouts⌄
Sim. Submódulos e sparse checkouts funcionam normalmente em worktrees, mas você precisa inicializá-los ou atualizá-los separadamente em cada worktree porque o conteúdo do diretório de trabalho não é compartilhado. Os dados subjacentes do Git ainda são compartilhados, mas os arquivos em checkout são independentes.
Saiba mais sobre o sistema de controle de versão mais conhecido e por que é uma ferramenta de colaboração indispensável para cientistas de dados e programadores.
Saiba como renomear ramificações locais e remotas do Git usando o terminal ou a interface gráfica do usuário (GUI) de clientes populares como o GitHub.
Saiba por que o git pull --force não é a melhor maneira de substituir uma ramificação local pela versão remota e descubra o método adequado usando git fetch e git reset.
O Git prune é um comando do Git que remove objetos do repositório que não são mais acessíveis a partir de qualquer commit ou branch, ajudando a liberar espaço em disco.
Você está trabalhando em uma feature quando um colega pede para você revisar o pull request dele. Dá para dar um stash, trocar de branch e torcer para lembrar de onde parou. Ou pode fazer um commit pela metade só para não perder o que estava fazendo. E ainda tem o hotfix de emergência: produção caiu, e você está no meio de um refactor que mexe em metade do código. Cada troca de contexto dessa custa 10–15 minutos de preparação e quebra totalmente o foco.
Git worktree resolve isso permitindo que você dê checkout em várias branches ao mesmo tempo, cada uma em um diretório separado. Em vez de fazer stash ou commitar trabalho incompleto, você simplesmente dá
cdpara outro diretório onde outra branch já está em checkout. Trabalhe no hotfix, faça o deploy e depois dêcdde volta para sua feature exatamente como você deixou.Neste tutorial, vou te mostrar como criar e gerenciar worktrees, evitar armadilhas comuns e integrar isso ao seu fluxo de trabalho diário. Você já deve entender branches e commits no Git e operações básicas de linha de comando. Se quiser revisar os fundamentos de Git antes, recomendo o tutorial Introduction to Git da DataCamp para cobrir o essencial.
O que é Git worktree?
Git worktree é um recurso nativo que cria diretórios de trabalho adicionais vinculados ao mesmo repositório. Seu diretório de trabalho principal é a worktree primária, e cada worktree extra que você cria ganha seu próprio diretório com sua própria branch em checkout. Todas essas worktrees se conectam ao mesmo repositório
.git.Essa arquitetura compartilhada significa que os commits feitos em qualquer worktree aparecem imediatamente no banco de dados do Git, acessível por todas as outras worktrees. Os arquivos em si ficam independentes — editar
train.pyem uma worktree só afeta aquele diretório até você commitar as mudanças.Por que não usar terminais diferentes?
Você não consegue abrir vários terminais no mesmo diretório e trabalhar em branches diferentes ao mesmo tempo. O Git só permite uma branch em checkout por diretório. Quando você roda
git checkout feature-bem um terminal, os arquivos mudam para todos os terminais apontando para aquele diretório.Git worktree resolve isso dando a cada branch seu próprio diretório. Cada diretório é totalmente independente, com seus próprios arquivos, processos em execução e artefatos de build. Trocar entre branches vira
cd ../outro-diretorioem vez degit checkout outra-branch.Pré-requisitos do Git worktree
Antes de usar git worktree, confira seu ambiente:
git --versionpara verificar. Git worktree saiu em 2015, então a maioria das instalações já temVeja se o worktree está disponível:
Se abrir a página de ajuda, está tudo pronto.
Quando usar git worktree
Git worktree é ótimo quando trocar de branch interromperia seu trabalho atual:
Evite para tarefas rápidas (menos de 10 minutos) em que
git checkouté mais simples, ou quando você está focado em uma única atividade sem interrupções previstas.Criando sua primeira worktree
A melhor forma de entender git worktree é criar uma e ver na prática. Vamos passar pelos comandos básicos, explorar a estrutura que o Git cria e observar como as mudanças fluem entre worktrees.
Configurando um repositório de exemplo
Antes de mergulhar em worktrees, você precisa de um repositório Git para usar. Se você já tem um projeto Python com várias branches, pule para a próxima seção. Caso contrário, vamos criar rapidamente um pipeline de ML simples:
Crie um README e um script Python:
Verifique se os arquivos foram criados:
Faça o commit desses arquivos e crie uma branch de feature:
Agora você tem um repositório com duas branches:
main(sua branch atual) efeature-preprocessing.Criação básica de worktree
Criar uma worktree para uma branch existente exige só um comando. Vamos dar checkout em
feature-preprocessingem um diretório separado:Isso cria um novo diretório chamado
ml-pipeline-preprocessingum nível acima do local atual, dá checkout na branchfeature-preprocessinglá e vincula ao seu repositório existente.O Git confirma a criação:
Para trabalho novo, crie a branch e a worktree de uma vez:
A flag
-bcria uma nova branch chamadafeature-visualizatione faz o checkout dela na nova worktree.Explorando a estrutura da worktree
Com a worktree criada, você agora tem múltiplos diretórios no sistema de arquivos. Para ver todos:
A primeira linha mostra sua worktree principal — o diretório original contendo a pasta
.git. A segunda linha mostra a worktree vinculada. Ambas exibem o hash do commit atual e a branch em checkout.Cada diretório de worktree funciona como um repositório Git completo. Você pode navegar até ele, editar arquivos, rodar
git statuse fazer commits. Worktrees vinculadas não contêm um diretório.gitcompleto — em vez disso, têm um arquivo.gitque aponta para o repositório principal. Dentro da pasta.gitprincipal, a pastaworktreesarmazena metadados de cada worktree vinculada.Trabalhando em uma worktree
Navegue até a worktree
feature-preprocessinge faça um commit:O commit acontece normalmente:
Volte para a worktree principal e veja o histórico de commits:
Seu novo commit aparece lá:
Repare como o commit aparece imediatamente nos dois locais sem comandos adicionais.
Casos de uso do Git worktree
Agora que você sabe criar e trabalhar com worktrees, vamos ver cenários práticos em que elas resolvem problemas reais de desenvolvimento.
Fluxo de code review
Seu colega precisa de feedback no PR. Em vez de fazer stash das suas mudanças e trocar de branch, crie um diretório separado para a revisão:
Teste as mudanças e deixe seu feedback. Ao terminar:
Seu trabalho original fica intocado. Sem stash e sem troca de contexto. Para mais estratégias de code review eficaz, confira o guia de boas práticas de code review da DataCamp.
Hotfixes de emergência
Sem worktrees:
Com worktrees:
Corrija e faça o deploy:
Você volta ao seu refactor em segundos, com todos os arquivos exatamente como estavam.
Desenvolvimento de features em paralelo
Você está implementando métricas customizadas e um novo data loader — duas features independentes. Crie uma worktree para cada uma:
Seu sistema de arquivos agora fica assim:
Rode as duas features em paralelo — cada uma no seu terminal:
Ambos os processos rodam ao mesmo tempo sem conflitos. Quando concluir uma feature, faça o merge e remova a worktree:
Gerenciando e limpando worktrees
Listando worktrees
Para ver todas as worktrees de um repositório:
Cada linha mostra o caminho do diretório, o hash do commit atual e a branch em checkout. A primeira entrada é sempre sua worktree principal (a que contém a pasta
.git), e as demais são worktrees vinculadas.Para scripts ou navegação rápida, extraia apenas os caminhos:
Removendo worktrees
Quando terminar o trabalho em uma worktree, remova-a corretamente:
O Git protege contra perda de dados. Se houver mudanças não commitadas:
Force a remoção se tiver certeza:
Se a worktree estiver bloqueada, use
--forceduas vezes:Se você apagou uma worktree manualmente (
rm -rfou gerenciador de arquivos), o Git ainda a rastreia internamente. Limpe referências obsoletas:Faça um ensaio do que seria removido:
Boas práticas e armadilhas comuns
Veja como tirar o máximo das worktrees e como evitar erros frequentes.
Organização de worktrees
Onde você coloca as worktrees faz diferença. A maioria dos devs cria diretórios irmãos ao repositório principal:
Essa estrutura mantém tudo no mesmo lugar e torna os caminhos previsíveis. O padrão
nomedoprojeto-nomedabranchdiz exatamente o que cada diretório contém.Alguns preferem uma pasta dedicada:
Escolha uma abordagem e use com consistência. Nomes descritivos como
ml-pipeline-user-authenticationtornam os diretórios autoexplicativos, enquanto genéricos comoml-pipeline-tempouml-pipeline-2te obrigam a checar o conteúdo. Trate worktrees como temporárias — crie para uma tarefa específica e remova quando terminar.Armadilhas comuns
Mesma branch em múltiplas worktrees
O Git impede dar checkout da mesma branch em duas worktrees:
Essa proteção existe porque você poderia fazer commits conflitantes. Se precisar do mesmo código em dois lugares, crie uma nova branch.
Worktrees esquecidas e espaço em disco
Cada worktree fica no seu disco até você removê-la explicitamente. Worktrees antigas se acumulam; projetos podem juntar 15+ worktrees esquecidas, consumindo gigabytes.
Cada worktree contém uma cópia completa dos arquivos do repositório. Um repositório de 500 MB com 5 worktrees consome 2,5 GB. Remova worktrees quando acabar:
Aninhar worktrees
Não crie uma worktree dentro do diretório de outra worktree. O Git até permite, mas isso confunde a estrutura de diretórios e torna a limpeza sujeita a erros.
Otimização do fluxo
Aliases no shell economizam tempo se você cria worktrees com frequência:
Para configurações mais complexas, escreva uma função que crie a worktree e configure seu ambiente de desenvolvimento em um passo:
O
${PWD##*/}extrai o nome do diretório atual. Rodarwt feature-logginga partir deml-pipelinecriaml-pipeline-feature-logging, navega para lá e configura um ambiente virtual Python com as dependências.Criar uma worktree vira um único comando:
Adapte para sua linguagem: substitua a configuração de Python por
bundle installpara Ruby,cargo buildpara Rust, ounpm installpara Node.js.Seu editor ou IDE funciona com worktrees sem configuração especial. Cada worktree é só um diretório, então abra como qualquer pasta de projeto. A maioria dos editores modernos permite abrir múltiplas raízes de projeto ao mesmo tempo — você pode ter três worktrees na mesma janela e alternar entre elas na barra lateral.
Worktrees avançadas: desenvolvimento paralelo com apoio de IA
Se você usa assistentes de código com IA, worktrees liberam um fluxo paralelo poderoso. Essa abordagem ganhou força entre devs e times em 2024–2025.
Crie worktrees separadas para tarefas diferentes:
Abra um painel de terminal para cada worktree e inicie seu assistente de IA:
Cada instância da IA trabalha em uma feature diferente sem interferência. Times relatam concluir trabalho em horas que antes levavam dias. Por exemplo, a incident.io roda 4–5 agentes do Claude Code em paralelo usando esse padrão. Em um caso, o Claude estimou uma melhoria de UI em 2 horas, mas terminou em 10 minutos.
Pontos de atenção:
Funciona bem para features grandes e independentes (30+ minutos cada), que não mexem nos mesmos arquivos, e quando você tem cota de API suficiente. Evite para correções rápidas, features muito acopladas ou quando estiver próximo dos limites de taxa da API.
Conclusão
Lembra do cenário do início — um colega precisa de review no PR enquanto você está no meio de uma feature. Agora você sabe a solução:
git worktree add ../ml-pipeline-review pr/branch-namee depoiscdpara começar a revisar. Sua feature fica intocada. Sem stash, sem commit pela metade, sem esforço mental para reconstruir o contexto quando voltar. Dois diretórios, duas branches, zero atrito.Git worktree não adiciona complexidade ao seu fluxo — ele remove. Cada worktree é só um diretório com uma branch em checkout. Mas essa simplicidade libera algo poderoso: a capacidade de alternar de contexto instantaneamente entre tarefas sem a carga cognitiva de fazer stash, dar checkout e reconstruir seu modelo mental.
Quando você precisar integrar worktrees a fluxos colaborativos como pull requests e code reviews, a trilha de habilidades GitHub Foundations da DataCamp cobre as práticas essenciais para trabalhar bem em times distribuídos.