Tino Gomes

Esse post é uma totalmente baseado, com algumas adaptações, do post do tapajós sobre o Rails for Kids, pois estou sem criatividade para escrever o meu próprio. Foi mal Tápa!

O Rails for Kids é uma maratona de palestras on-line que será realizado no dia 12/09/2009, e contará com grandes nomes da comunidade Ruby on Rails do Brasil e de fora.

São 14 palestras on-line e ao vivo durante o dia inteiro, usando um ambiente de eventos multimídia onde os palestrantes ministrarão seus temas através de recursos de audio, vídeo, slides e chat.

Qualquer pessoa, empresa ou faculdade pode participar do evento, para isto basta fazer uma doação de um valor simbólico de R$ 30,00 para ter acesso as palestras ao vivo e suas gravações que estarão disponíveis uma semana após a realização do evento.

Todo dinheiro arrecadado será doado ao Cotolengo de Mato Grosso do Sul.

Eu fui convidado pelo me convidei com o Carlos, da e-Genial, e farei uma palestra Git e tentar explicar alguns conceitos, como usar no dia-a-dia e nas horas de sufoco.

Mais uma vez, desculpe Tápa por copiar seu post sem perguntar antes, mas creio que você não vai ficar chateado com isso, né?

Como acabei de “twittar”, fiz cagada bagunça em um branch ao usar o git rebase. Antes de me desesperar, resolvi fazer a velha busca no “Pai” (termo usado para identificar o Google pelo famosíssimo Guanabara em um dos guanacasts sobre SEO (parte I e parte II), onde encontrei um post de Greg DeVore, explicando como recuperar uma cagada bagunça dessa. E com meus MAD SKIILS, ainda usei o git cherry-pick para recuperar o commit perdido. Lembrando que deve haver forma mais higiênica de recuperar um commit “perdido”. Bom, chega de bla-bla-bla e vamos ao que interessa. (os hashes de commit foram abreviados para facilitar a leitura)

$ echo NÃO SE DESESPERAR
NÃO SE DESESPERAR
$ cat .git/logs/refs/meu-branch
937 a0e tino ...commit: meu commit 2
a0e 1eb tino ...commit(amend): meu commit 2
1eb 8db tino ...rebase (finish): refs/heads/meu-branch onto 8db
$ echo NOTE QUE NO COMMIT "1eb" FOI O ÚLTIMO ANTES DO rebase
NOTE QUE NO COMMIT "1eb" FOI O ÚLTIMO ANTES DO rebase
$ git cherry-pick -n 1eb
Finished one cherry-pick.
$ git status
...
modified app/controller/application_controller.rb
...
$ git commit -m 'meu commit 2'
[meu-branch 3f5f542] meu commit 2
 15 files changed, 157 insertions(+), 21 deletions(-)

Pronto, seu trabalho foi recuperado!

Preparando um material para falar sobre git, algumas técnicas e outras dicas, dentre elas resolvi demostrar o uso do git bisect, e usei como base o post do Arthur Geek. Então, resolvi fazer uma aplicação nada trivial (um blog) e em um certo ponto dos commits, forcei um erro para usar o git bisect e encontra-lo. Aproveitei para dar uma lida na documentação para pegar mais algum detalhe e me deparei com a opção “run” que automatiza a busca pelo commit ruim, usando um script ou comando que avalia o ponto de parada. Como na minha aplicação exemplo estava coberta por testes e o erro forçado era capturado, logo ficou muito mais legal. Abaixo segue resumido os passos seguidos, mas todo o console você dá uma olhada no meu gist.

1) Listando o log de commits para identificar um ponto bom e outro ruim.
$ git log
2) Após identificados os commits, iniciando o git bisect
$ git bisect start HEAD a17411e98d7b5
3) Deixando o git bisect buscar o ponto de inicio da falha, com rake test:units
$ git bisect run rake test:units
4) Identificado o ponto de erro, então vamos para o git bisect
$ git bisect reset
5) Vamos listar o diff entre os commits com erro e anterior
$ git diff 7d91b350196ccc 0765b113edefb9

* as chaves de commit acima foram abreviadas para facilitar, mas está completo no log