Git: nem tudo está perdido

Entendendo o problema na prática

Pra reproduzir o acontecido, vou dar um git log na master do repositório do Alura e um reset --hard voltando a apontar pro penúltimo commit. Repara que tem um commit meu, adicionando um alarme de 80% de CPU em nosso servidor, e depois do reset a master volta a apontar pro commit do Philippe Ehlert, que antecedia:

Pronto, agora é só fazer um push -f origin master e se arrepender 2 segundos depois.

Em busca do commit perdido

A notícia boa é que mesmo que você tenha feito um reset, o commit continua lá... ele não é apagado! Ou seja, você pode recuperar qualquer commit se você souber o SHA1 dele. Se você não está acostumado com esse termo, SHA1 nada mais é do que esse hash bonitão (único) que identifica um commit:

Mas como eu vou saber o SHA1 se eu já fiz um reset e ele não aparece mais no log? A resposta é simples: toda mudança que você faz na HEAD de uma branch fica registrado em um lugar conhecido como reflog, que pode ser consultado com o comando git log -g:

Repara que primeiro eu fiz um git log normal, meu commit não estava lá... depois um git log -g e voilà, tenho o registro de tudo o que aconteceu na minha branch. Legal, não acha? O reflog tem muito mais informações que podem ser úteis, se você for curioso como eu, já deve estar googlando pela sua documentação.

Voltando o commit pra master

Agora que eu já tenho o SHA1 do meu commit eu posso, entre outras opções, fazer um cherry-pick desse commit de volta pra master. Não tem segredo, basta rodar git cherry-pick [SHA1] e pronto:

Ufa, problema resolvido.

Essa é uma regra valiosa do Git: se você commitou alguma coisa, provavelmente dá pra recuperar. Se você não commitou, bem... já foi! Por isso é importante fazer commit e se possível push de tudo com a maior frequência possível, falamos bastante disso no curso de Git do Alura e no curso de práticas ágeis daqui da Caelum.

E você, o que mais tem feito de legal com Git? Já perdeu algum commit e não conseguiu recuperar?