APRENDER. PRATICAR. EVOLUIR.Definir o âmbito antes de mudar de contexto
Uma equipa APS fictícia recebe um incidente no fecho diário enquanto prepara uma funcionalidade. A correção tem de partir da release aprovada; o index atual contém trabalho ainda não revisto. Antes de executar comandos, identifica a base da release, o trabalho preparado, as edições restantes e os ficheiros não acompanhados que interessam à investigação. A pergunta operacional é: como preparar uma alteração pequena sem perder nem incluir acidentalmente o trabalho pendente? Escreve a decisão e a evidência que vais recolher. Um nome de branch ou uma mensagem hotfix não comprova a seleção correta do conteúdo.
Comparar duas worktrees no laboratório
No laboratório local, app.txt começa com base. A worktree principal prepara a alteração draft e guarda a diferença preparada. Depois, worktree add -b urgent cria outra worktree a partir de HEAD. Na nova pasta, app.txt continua com base e o index não tem alterações. Após um commit de correção nessa worktree, o diff preparado na principal permanece igual. O runner confirma estas observações em repositórios temporários. O exercício usa Git 2.50.1 Apple Git-155; a documentação atual consultada é da linha 2.56. Não foi executada uma aplicação nem validada uma release real.
Reconhecer o que continua partilhado
A separação de index e HEAD não cria dois repositórios independentes. A branch urgent ficou visível a partir da worktree principal e ambas apontaram para o mesmo diretório comum do repositório. Isto importa quando uma equipa muda referências ou configuração: por omissão, a configuração do repositório é partilhada. Não uses outra worktree como fronteira de autorização ou cópia de segurança independente. Na reunião de mudança, explica que separaste o trabalho em edição, mas continuas a precisar de coordenação sobre branches e publicação. Para configuração específica, revê o mecanismo worktreeConfig e a compatibilidade das versões em uso.
Escolher o que guardar com stash
Noutro laboratório, app.txt tem uma edição acompanhada, notes.txt é não acompanhado e cache.tmp é ignorado. Stash push -u guarda os dois primeiros; cache.tmp permanece. Stash apply repõe o trabalho e conserva a entrada para revisão. Pede ao formando que compare status, diff e stash list antes de considerar a tarefa concluída. Se interessa repor também a seleção preparada, a opção --index tenta fazê-lo, mas pode falhar com conflitos. Um pop com conflito não elimina automaticamente a entrada. Evita repetir o comando por impulso: interpreta primeiro o estado e a intenção das alterações.
Fechar a correção com evidência
Entrega uma nota que identifique o commit de base, o commit de correção, os ficheiros alterados e os testes feitos no contexto da release. Antes de remover a worktree, confirma se existem diagnósticos ou edições não guardadas. Um diff vazio sobre ficheiros acompanhados não exclui ficheiros não acompanhados. O runner content/labs/git-recovery/run.py reproduz as experiências locais sem remotos, configuração pessoal, hooks ou assinaturas. Resumo: separa a seleção do commit, confirma o âmbito do stash e preserva evidência antes de limpar. Relaciona esta aula com index, remotos, revisão de código e gestão de incidentes.
O diff preparado principal ficou igual depois de criar e alterar a worktree urgente.
Armadilhas comuns
Worktree como clone independente; -u como inclusão de ignorados; pop em conflito como entrada perdida.
Tópicos relacionados: Working tree, index e commit · Branches, merge e rebase · Reverter alterações e preservar trabalho
Separa os contextos e verifica explicitamente o trabalho que cada operação conserva.
Referência: Git: worktree · Git 2.56; workflow concepts compatible with modern Git 2.x