Por que cada novo worktree parece uma instalação nova
Git worktrees oferecem uma maneira poderosa de gerenciar múltiplas branches simultaneamente. Eles compartilham o histórico de um único repositório, mas cada worktree mantém um diretório de trabalho separado. Essa separação é fantástica para desenvolvimento paralelo, como quando você está alternando entre várias funcionalidades ou implantando múltiplos agentes de codificação de IA.
Aqui está o problema: um worktree novo começa quase vazio. O Git copia seu código, mas ignora intencionalmente arquivos e diretórios não rastreados. Isso significa que componentes cruciais como node_modules para projetos JavaScript, arquivos de configuração ..env ou o diretório de build target/ do Rust ficam completamente ausentes.
Consequentemente, cada novo worktree exige um cold install completo e um processo de build. Você deve reinstalar dependências, recompilar código e regenerar caches. Imagine rodar cinco ou dez agentes de codificação, cada um precisando do seu próprio .environment.
Cada agente então realiza seu próprio npm install, cargo build ou outra configuração. Isso multiplica o esforço: cinco agentes significam cinco instalações separadas, cinco builds a frio e cinco vezes o espaço em disco consumido. Antes mesmo de qualquer trabalho útil começar, você gastou tempo significativo, ciclos de CPU e gigabytes de armazenamento apenas preparando as coisas.
O atalho copy-on-write por trás da aceleração
Worktrunk, uma CLI Rust de código aberto, oferece uma solução inteligente com seu comando wt step copy-ignored. Este utilitário aproveita o copy-on-write (CoW), um recurso de sistema de arquivos, para trazer arquivos ignorados selecionados para um novo worktree quase instantaneamente, sem uma cópia completa tradicional.
Copy-on-write é um truque elegante: os arquivos inicialmente compartilham os mesmos blocos de disco subjacentes. Quando você modifica um arquivo em um worktree, o sistema de arquivos copia apenas os blocos alterados para um novo local. Isso preserva o isolamento entre os worktrees enquanto evita o custo inicial de duplicar arquivos massivos. É como ter múltiplas cópias que magicamente só ocupam espaço quando realmente divergem.
Essa abordagem acelera drasticamente a configuração. O vídeo destaca ganhos impressionantes: copiar uma pasta de build Rust de 14 GB supostamente cai de cerca de dois minutos para aproximadamente 20 segundos. Melhor ainda, um primeiro build, que normalmente levaria cerca de 68 segundos em um worktree novo, pode cair para apenas três ou quatro segundos.
Estes são resultados relatados pelo autor, demonstrando o potencial em sistemas de arquivos que suportam reflinks, como APFS do macOS ou btrfs e XFS do Linux. Embora não seja um resultado garantido para todas as configurações, esses números ilustram a redução significativa de cold start que o CoW pode proporcionar, especialmente ao trabalhar com grandes caches de build ou diretórios node_modules.
Verifique seu sistema de arquivos antes de esperar mágica
Antes de esperar resultados instantâneos, é crucial confirmar as capacidades do seu sistema. Copy-on-write (CoW), ou reflinks, depende do seu sistema de arquivos e configuração. Muitos Macs rodando APFS e sistemas de arquivos Linux como btrfs e XFS suportam esse recurso, mas configurações não suportadas voltarão para uma cópia tradicional e mais lenta.
Crucialmente, CoW é distinto de hard links ou diretórios mutáveis compartilhados. Quando você modifica um arquivo em um worktree, o sistema de arquivos duplica apenas os blocos alterados, garantindo que o arquivo do outro worktree permaneça intocado. Isso evita alterações silenciosas e inesperadas em seus .environments paralelos.
Para entender verdadeiramente o impacto, você deve testar o comando wt step copy-ignored do Worktrunk em seu projeto e drive reais. Meça tanto o tempo decorrido quanto o uso do disco. Fatores como gerenciadores de pacotes, caches de ferramentas de build e até mesmo configurações de .worktreeinclude (para controle granular sobre o que é copiado) podem influenciar os resultados.
Por exemplo, uma pasta de build de Rust de 14 GB copiada normalmente leva cerca de dois minutos e consome 14 GB adicionais. Com reflinks, isso pode cair para cerca de 20 segundos e praticamente zero espaço em disco adicional. Isso reduz drasticamente os tempos de cold build de aproximadamente 68 segundos para apenas 3-4 segundos. Saiba mais sobre como otimizar seus fluxos de trabalho Git para agentes de IA paralelos com o Worktrunk em Worktrunk — Git worktree management for parallel AI agent workflows. Lembre-se, esses números são ilustrativos; sua experiência pode variar!
Gostando do artigo? Receba um assim na sua caixa de entrada toda manhã.
um e-mail por dia · cancele em dois cliques · sem rastreadores de terceiros
Torne as inicializações rápidas seguras — e repetíveis
Automatize o wt step copy-ignored adicionando-o aos hooks de ciclo de vida do Worktrunk. Isso garante que novos worktrees herdem automaticamente caches úteis, mas use um arquivo .worktreeinclude para especificar quais caminhos ignorados copiar. Por exemplo, inclua target/ para projetos Rust ou node_modules/ para JavaScript, mas exclua arquivos de log temporários.
Selecione os caminhos deliberadamente. Arquivos ..env geralmente contêm segredos e, em geral, não devem ser copiados. Caches e artefatos gerados também podem estar obsoletos ou ser específicos do ambiente, levando potencialmente a problemas difíceis de depurar. Nem todo arquivo ignorado é seguro ou benéfico para compartilhar; escolha com cuidado.
Implemente esta otimização com cautela. Primeiro, teste em um único worktree. Verifique o isolamento adequado e a correção do build. Compare o cold start do novo worktree com uma configuração completamente limpa para confirmar a aceleração, que pode ser tão drástica quanto reduzir um build de Rust de 68 segundos para 3–4 segundos.
Uma vez validado, automatize a etapa de cópia para o fluxo de trabalho de agentes da sua equipe. Isso garante consistência e maximiza os benefícios do provisionamento quase instantâneo de worktrees, transformando cold starts em começos produtivos e ágeis.
Perguntas Frequentes
O que o comando copy-ignored do Worktrunk faz?
Ele copia arquivos gitignored de um worktree existente para um novo, usando copy-on-write onde o sistema de arquivos oferece suporte.
O copy-on-write funciona em todos os drives?
Não. Depende do suporte do sistema de arquivos e da plataforma. APFS, btrfs e algumas configurações de XFS suportam reflinks; caso contrário, a cópia pode consumir mais tempo e espaço em disco.
Arquivos .env são seguros para copiar para outro worktree?
Apenas se os mesmos segredos e configurações forem apropriados lá. Revise o que você inclui e evite compartilhar credenciais com projetos ou agentes não confiáveis.
Como uso o comando?
Instale o Worktrunk e execute wt step copy-ignored como parte da configuração do seu worktree. Verifique a documentação do Worktrunk para opções e configurações atuais.