APRENDER. PRATICAR. EVOLUIR.Separar conteúdo, referência e edição local
Um técnico cria uma correção num checkout destacado e muda depois para main. A correção pode continuar como objeto mesmo sem branch própria. Outra situação é um ficheiro nunca guardado em Git que desaparece do filesystem. Não são o mesmo problema. Para o primeiro, investiga referências e reflog local; para o segundo, procura cópias do editor, backups ou outros mecanismos apropriados. Antes de qualquer recuperação, preserva a edição atual e identifica o que realmente se perdeu: uma referência, um commit, uma seleção no index ou um ficheiro nunca registado.
Resgatar um commit observado
No laboratório, switch --detach permite criar um commit experimental sem avançar main. Depois de regressar a main, o runner encontra o ID no reflog de HEAD e cria uma branch rescue nesse ID. Show rescue:app.txt confirma o conteúdo. Criar a referência não exige fazer reset da worktree atual. Numa investigação real, inspeciona o candidato antes de o integrar: mensagens semelhantes não garantem a mesma correção. A experiência não recupera ficheiros nunca guardados e não testa retenção após limpeza. O reflog é local e pode expirar; não deve ser o único plano de cópia de segurança.
Escolher o antecessor de um merge
A reversão de um merge precisa de uma linha principal de comparação. Inspeciona o objeto e os antecessores, por exemplo com log --format=%P -1 M, e relaciona-os com a integração efetuada. Não escolhas -m 1 apenas por hábito nem infiras a ordem a partir das datas de mensagens. No laboratório, main integra feature com --no-ff; o primeiro antecessor representa a linha principal que se pretende manter. Revert --no-edit -m 1 M cria uma alteração compensatória e o conteúdo da feature desaparece. Este exercício local explica a escolha; não valida uma reversão de dados de aplicação.
Explicar por que o mesmo merge não repõe a feature
Após a reversão, o laboratório volta a executar merge feature sem novos commits na origem. HEAD não muda e a feature continua ausente do ficheiro. O merge anterior permanece na ancestralidade: o conteúdo foi compensado, mas a história de integração não foi apagada. Este é um ponto útil numa reunião de incidente, quando alguém propõe repetir o merge para repor o comportamento. A equipa precisa de planear uma reintrodução corrigida, que pode envolver reverter a reversão ou novos commits conforme a história. Reintroduzir o conteúdo sem corrigir o defeito original repete o risco funcional.
Comunicar a recuperação e os seus limites
Entrega uma explicação com o objeto encontrado, a referência criada, o conteúdo confirmado e os testes ainda necessários. Num merge revertido, inclui o gráfico de antecessores e a estratégia de reintrodução. O runner guarda seis grupos de observações e o hash do seu próprio artefacto em evidence.json. Os comandos foram executados em repositórios descartáveis, sem remotos nem dados do projeto real. Resumo: um commit sem branch pode ser resgatado enquanto existir; reflog não é um backup ilimitado; revert não apaga a ancestralidade. Relaciona a aula com recuperação, rastreabilidade de releases e validação funcional.
O commit destacado foi resgatado; o mesmo merge após revert não voltou a introduzir a feature.
Armadilhas comuns
Reflog como cópia de todos os ficheiros; reset antes de preservar trabalho; revert como apagar a história.
Tópicos relacionados: Working tree, index e commit · Branches, merge e rebase · Reverter alterações e preservar trabalho
Preserva referências e interpreta a ancestralidade antes de prometer recuperação funcional.
Referência: Git: reflog · Git 2.56; workflow concepts compatible with modern Git 2.x