O que são git worktrees e por que você deveria usá-los?

Git worktrees são um recurso nativo do Git que permite vincular múltiplos diretórios de trabalho a um único repositório, sem duplicar o histórico (`.git/objects`). Introduzido oficialmente no Git 2.5, em 29 de julho de 2015, o comando `git worktree` era inicialmente experimental e pouco integrado a ferramentas. Sua adoção só ganhou tração recentemente, impulsionada por necessidades práticas como desenvolvimento paralelo, revisão local de pull requests e, mais recentemente, pelo suporte nativo do Visual Studio Code a worktrees, implementado em julho de 2025. A partir do Git 2.7, foram adicionados comandos essenciais como `git worktree list`, `git worktree move` e `git worktree remove`; já no Git 2.15 e 2.17, chegaram `git worktree lock` e `git worktree prune`, respectivamente, tornando o gerenciamento mais seguro e sustentável.

Cada worktree opera com seu próprio `HEAD`, index e estado de arquivos de trabalho, mas compartilha todos os commits, objetos e referências do repositório principal. Isso significa que um commit feito em um worktree está imediatamente acessível em outro, sem precisar de `git push` ou `git fetch`. É uma alternativa técnica e eficiente ao `git clone` para cenários de multitarefa, não uma camada de abstração externa ou plugin.

O valor real dos git worktrees está na eliminação de fricções operacionais antigas: trocar de branch não exige `git stash`, `git commit --amend` ou `git reset` para salvar estado intermediário; testar uma correção crítica enquanto desenvolve uma nova feature não exige esperar rebuilds ou reinstalação de dependências; revisar um pull request não exige sair do branch atual nem correr risco de conflitos de estado da IDE. Essa isolação contextual é especialmente relevante em projetos com tempos longos de build, ambientes complexos de dependência (como monorepos com Yarn Workspaces ou Nx), ou quando agentes de IA precisam operar em tarefas concorrentes sem interferir no fluxo humano. Não é sobre ter 'mais branches', é sobre ter múltiplos contextos de execução ativos ao mesmo tempo, com custo quase zero de infraestrutura.

Para devs, git worktrees mudam o ritmo do dia a dia: `git worktree add ../feature-login main` cria um diretório separado já com a branch `main`, pronto para checkout de `feature-login` sem afetar o diretório principal. Nenhum `git stash pop` esquecido, nenhuma IDE travando ao reindexar 50 mil arquivos ao mudar de branch. Ferramentas como VS Code reconhecem automaticamente cada worktree como um workspace independente, incluindo extensões de lint, debug e integração com GitHub Copilot CLI. O único trade-off real é operacional: é preciso lembrar onde cada worktree está (`git worktree list` resolve isso) e evitar deletar diretórios manualmente, caso contrário, metadados órfãos exigem `git worktree prune`. Mas essa é uma prática simples, documentada e consolidada desde o Git 2.17.