Recuperar commits e branches perdidos com o reflog

Objetivo

Recuperar commits que parecem ter desaparecido depois de git reset --hard, de um rebase que deu errado, de git commit --amend ou da exclusão de uma branch, sem ter de adivinhar IDs de objetos.

Pré-requisitos

O trabalho foi commitado (ou ao menos adicionado ao stage) em algum momento neste repositório. O reflog é local: ele registra quando as pontas das branches e de outras referências foram atualizadas neste clone, conforme afirma a documentação do git-reflog. A coleta de lixo ainda não expirou as entradas; os padrões documentados são 90 dias (gc.reflogExpire) e 30 dias para entradas que já não são alcançáveis a partir da ponta da branch (gc.reflogExpireUnreachable).

Passos

1. Pare de fazer alterações. Não execute git gc, git prune nem git reflog expire até concluir a recuperação.
2. Execute git reflog para ver o de HEAD, ou git reflog show <branch> para uma branch específica. Cada linha tem o formato HEAD@{n}: <action>: <message>; HEAD@{2} significa o segundo valor anterior de HEAD, e main@{yesterday} também é válido (o gitrevisions documenta tanto a forma ordinal quanto a de data).
3. Localize a entrada imediatamente anterior à ação que causou o dano, pelo rótulo: reset:, rebase (start), commit (amend), checkout:.
4. Inspecione antes de mexer em qualquer coisa: git show HEAD@{3}, git log --oneline -5 HEAD@{3}, git diff HEAD HEAD@{3} --stat.
5. Primeiro, crie uma branch na posição antiga: git branch rescue HEAD@{3}. Depois, faça merge, cherry-pick ou git reset --hard rescue a partir de um estado seguro.
6. No caso de uma branch excluída, o reflog dela desapareceu, mas o reflog de HEAD ainda lista os commits e checkouts feitos nela; busque com git reflog | grep <keyword>.
7. Se nada no reflog corresponder (por exemplo, depois de git stash clear), execute git fsck --lost-found; ele grava os commits pendentes (dangling) em .git/lost-found/commit/ e, no caso de blobs pendentes, o próprio conteúdo em .git/lost-found/other/. Às vezes é possível encontrar assim versões de arquivos que estavam no stage mas não foram commitadas.

Resultado esperado

Os commits perdidos voltam a ser alcançáveis a partir de uma branch nomeada, e a recuperação deixa a branch atual intacta até você decidir como combinar as duas.

Limites e base de verificação

O reflog nunca contém alterações da árvore de trabalho que não foram commitadas nem adicionadas ao stage; essas estão perdidas. Um clone novo tem o reflog vazio, e um colega não consegue recuperar a sua perda a partir do reflog dele. As entradas só sobrevivem até expirarem ou até um git reflog expire explícito. O comportamento descrito segue a documentação citada; não se afirma nenhum tempo de execução.