Git além do commit

Git guarda snapshots endereçados por hash. Uma branch é apenas um nome que aponta para um commit; HEAD aponta para a branch (ou diretamente para um commit). Esse modelo torna recuperação menos misteriosa e evita usar comandos destrutivos por reflexo.

Antes de mexer, veja o estado

git status --short
git log --oneline --graph --decorate -12
git fetch origin --prune
git branch -vv

Use merge quando o histórico compartilhado deve registrar a integração de duas linhas. Use rebase para reaplicar commits locais ainda não publicados sobre uma base nova e produzir uma sequência linear. Nunca reescreva uma branch que outras pessoas usam sem acordo explícito; após rebase de uma branch publicada, --force-with-lease protege contra sobrescrever commits remotos que você não tinha visto.

git switch minha-feature
git rebase origin/main
git push --force-with-lease origin minha-feature

Ao resolver conflito, leia a intenção dos dois lados, rode os testes e então use git add arquivo seguido de git rebase --continue. --abort volta ao ponto anterior se a resolução estiver errada. Não aceite automaticamente todos os conflitos: código que compila pode perder uma regra de negócio.

Encontre e recupere um erro

Para localizar a mudança que introduziu uma regressão entre uma revisão boa e uma ruim:

git bisect start
git bisect bad HEAD
git bisect good v1.4.0
# teste cada revisão indicada e marque: git bisect good | git bisect bad
git bisect reset

Para recuperar um commit ou branch “sumido”, procure primeiro no reflog local:

git reflog --date=local
git switch -c recuperar 1a2b3c4

O reflog expira; quanto antes criar uma referência, maior a chance de recuperação. Para desfazer uma mudança já publicada, prefira git revert <commit>: ele cria um novo commit inverso e preserva o histórico compartilhado.

Próximo passo: padronize revisão e proteção de branch na trilha de Versionamento. Só automatize hooks locais como conveniência; a validação obrigatória deve rodar também no CI.