Recupere mudanças e reorganize uma branch com segurança

Recuperar no Git começa com uma pergunta: onde está a mudança? Uma linha pode estar apenas na working tree, no stage, num commit local ou num commit já compartilhado. Usar o comando certo no estado errado transforma uma correção pequena em perda ou reescrita desnecessária.

Para uma edição não preparada que você realmente quer descartar, revise o diff e restaure:

git diff -- catalogo.txt
git restore catalogo.txt

Esse conteúdo nunca virou commit; reflog não promete recuperá-lo. Para retirar um arquivo do stage sem apagar a edição, use git restore --staged catalogo.txt. O status muda de M para M. Essa diferença de coluna é a prova de que a working tree continua intacta.

Um commit compartilhado pede outra estratégia. git revert HASH cria um novo commit com o patch inverso. Causa e correção permanecem no log que o time já conhece. Revert pode conflitar se mudanças posteriores tocaram a mesma região; resolva, teste e conclua como merge.

Reset move a branch. --soft mantém mudanças no stage, --mixed preserva na working tree e --hard alinha as três áreas, descartando alterações rastreadas. Não comece por hard. No laboratório, crie três commits, anote o hash da ponta, execute um reset e consulte:

git --no-pager reflog -5

O reflog registra movimentos locais recentes de HEAD. Use o hash que sua execução mostrou para recuperar. Ele não contém trabalho nunca commitado e suas entradas expiram; é uma rede de segurança, não política de backup.

Stash resolve uma interrupção curta. Dê nome à entrada e inclua arquivo novo somente quando necessário:

git stash push -u -m "busca pela metade"
git stash list
git --no-pager stash show -p stash@{0}

apply recupera e mantém a entrada; pop tenta recuperar e remover. Se houver conflito, pop conserva o stash. Resolva antes de aplicar outro. Trabalho que precisa durar ou ser compartilhado deve virar commit numa branch, não morar indefinidamente na pilha local.

Rebase é outra categoria: ele reaplica commits sobre uma base e cria hashes novos. Use para atualizar e organizar sua branch de tarefa quando ninguém depende daqueles hashes. Não rebase main compartilhada. Antes, crie uma branch de segurança e faça fetch:

git branch seguranca/antes-rebase
git fetch origin
git rebase origin/main

Se parar em conflito, resolva o patch atual, execute add e git rebase --continue. --abort devolve o estado inicial. --skip descarta o patch atual e só serve quando você provou que ele já existe ou não é desejado.

O erro típico é usar push --force depois de rebase sem conferir se outra pessoa avançou a branch. Quando a política permite reescrever uma branch pessoal, --force-with-lease adiciona a condição de que o remote ainda esteja na ponta observada. Mesmo assim, avise quem revisa.

Feche montando uma tabela própria: estado, intenção, comando e risco. Execute o desafio somente em diretório temporário. Você conclui quando consegue recuperar o hash anotado, explicar por que revert preserva a conversa e justificar rebase pelo público da branch, não pela aparência do log.