25
willybr
2 min de leitura ·

Pare de usar Git Stash pra trocar de branch. Existe algo muito melhor.

Você está no meio de uma feature, surge um PR pra revisar ou um hotfix urgente. O que você faz? git stash, troca de branch, faz o que precisa, volta, git stash pop... torce pra não ter conflito, lembra qual stash era o certo, e reza pro estado voltar como estava.

Ou pior: faz aquele commit "wip asdasd", troca de branch, depois volta e dá reset --soft. Todo mundo já fez isso.

O problema é que nenhuma dessas abordagens foi feita pra isso. Stash é pra guardar mudanças temporárias, não pra ficar alternando entre trabalhos. E commits WIP poluem o histórico.

Git Worktree

Existe uma funcionalidade nativa do Git, disponível desde 2015, que resolve exatamente esse problema: Git Worktree.

git worktree add ../meu-projeto-wt/hotfix hotfix/urgente

Fizemos um vídeo explorando git worktrees: https://youtu.be/KigDh1IW2QQ

Esse comando cria uma pasta separada com o checkout daquela branch. Pronto. Você tem duas branches abertas ao mesmo tempo, cada uma na sua pasta, sem stash, sem commit fake, sem clonar o repo de novo.

Quando terminar, remove:

git worktree remove ../meu-projeto-wt/hotfix

Como tudo compartilha a mesma referência Git, git fetch atualiza tudo, e merge/cherry-pick entre branches locais funciona normalmente.

Cuidado: arquivos do .gitignore (node_modules, .env) não são copiados pra nova worktree. Precisa rodar install e copiar configs. Pra automatizar isso, vale dar uma olhada no Worktrunks, um wrapper que adiciona hooks de setup automático, hash de portas pra rodar múltiplas instâncias, e cleanup completo.

Com agentes de IA precisando rodar em paralelo no mesmo repo, worktrees ficaram ainda mais relevantes. Mas mesmo sem IA, se você usa stash pra trocar de branch, worktree é uma alternativa muito mais limpa.

Links

✨ Curtiu o post?
Esse tipo de papo rola na Craft & Code Club, comunidade gratuita onde nos ajudamos evoluir como engenheiros de software, e em questões de carreira (e onde rola nosso clube do livro também).

💬 O coração da comunidade é o Discord: https://discord.gg/cqF9THUfnN
🌐 Conheça tudo: https://craftcodeclub.io

Vamos juntos!

Carregando publicação patrocinada...
5

Meu cents para você!

Gostei da maneira que você apresentou essa feature... Eu utilizo o worktree do GIT para dar deploy em alguns APPs no servidor, mas realmente nunca tinha passado pela minha cabeça em utilizar ele para HOTFIX.

2
4

Excelente. Realmente e uma feature pouco divulgada/conhecida.

No meu caso, uso o stash do git ou o shelf do Intellij.
Projetinho monolito com mais de 2GB (600MB só de código fonte e mais um tanto de dependências e arquivos de build) e bastante configuração, ficar criando cópia não fica muito viável.

Ainda assim, vejo que é viável para boa parte dos casos, porque os projetos não costumam ser tão grandes assim (exceto pastas de virtualenv ou node_modules).

2

Esse último parágrafo, sobre o worktree ter ficado importante com os agentes de IA rodando em paralelo, é exatamente o que eu faço todo dia. Rodo vários agentes no mesmo repo ao mesmo tempo, e o worktree é a base disso.

Quando cada agente tem a própria árvore de trabalho, um não pisa nas mudanças não commitadas do outro. Com stash não dá: só existe uma árvore de trabalho, então o paralelo simplesmente não fecha.

O Claude Code que eu uso passou a recomendar oficialmente as sessões paralelas com worktree faz pouco tempo, e lembro até hoje da animação quando isso saiu. O dia a dia ficou bem mais estável. É como o texto diz: a IA fez a galera redescobrir o valor do worktree.

Você usa worktree pros seus agentes rodarem em paralelo?

1

Eu aprendi a usar worktree exatamente por causa dos agentes de IA. O openchamber (interface para o opencode) twm um atalho que criar worktrees. Fui pesquisar a fundo do que se tratava e acabei aprendendo como funciona.

Depois disso sempre crio agentes usando subagents em worktrees distintas.

1

Não sou muito fã porque ele gera quase como um clone novo do repositório, exigindo configurar .env, launch.json e etc. tudo de novo. Até rodar corretamente prefiro o velho e, muitas vezes problemático, git stash. Sou dev java.

1
1

Sim, o importante é seguir a maneira que esteja mais confortavel e produtivo!

Mas daqui a gente criar scripts que sao executados na hora que uma worktree é crida, as ferramentas já facilitam bem isso, claude tem hooks, cursor tem hooks tbm, worktrunk tambem.

Fazendo com que sempre que uma worktree é criada, o script já execute um dos dois caminhos abaixo:

  • Instala as dependencias e copia o .env

  • Ou simplesmete copia a pasta de dependencias e o .env (bem mais rapido)

Ao menos na minha experiencia, o script nunca deu problema, e normalmente quando mudo o foco para trabalhar na worktree ja esta tudo pronto ali.

Mas novamente, é apenas um dos possiveis approaches né, git stash está entre nós para ser usado mesmo hehe

Abração!

1

É uma boa dica para codebases pequenas. Codebase grande seria mais desagradável fazer esse tipo de coisa e acabaria sendo mais prático usar git stash mesmo.

1

Eu diria que depende um pouco, varia mais pelo tanto de dependencias e como está as configurações do projeto. Digo isso porque trabalho em enterprise, com codebases de mais de 20 anos (codebases muito grandes), bem parrudas, entre legados monlíticos em Java ou C#, e novos projetos seguindo micro-servicos com as mesmas tecnologias + JS/TS.

O maior deasfio dentre todos estes projetos é o node com TS, e como as dependencias, build e demais processos a depender de quantas dependencias acaba ficando oneroso, já que uma worktree acaba por startar um repo do zero. Aqui vejo 3 possibilidades:

  • Seguir com stash, e tudo bem rs (com os mesmos trade-offs tratados no texto)

  • Utilizar um script nos hooks para já executar o processos de instalar dependencias + build + setar os envs necessarios (ferramentas como o worktrunk deixam isso bem mais fácil)

  • Utilizar script e hooks para apenas copiar e nao reinstalar tudo do zero, assim sempre que uma worktree é criada ela levara as pastas de dependencias, caches de build, .envs necessarios e ja setar o que mais precisar.

Ao menos estas são as maneiras que usamos por aqui, porém em stacks como .Net, mesmo o legado de 20 anos, builda e esta pronto para rodar em alguns segundos, o que faz o fluxo ser bem adotado nas equipes que trabalham com a stack, independente do tamanho do projeto.

Meus pontos com este comentário, é que sim, concordo que há desafios e nuances a depender da codebase e como ela é estruturada, e mesmo a stack impacta; o único contra-ponto que penso, é que isso não necessariamente vai depender de tamanho da codebase.