Update: Aqui estão os slides da palestra: Git: Controle de Versões do jeito certo

Não deixe de conferir (e assistir) as outras palestras que vão rolar esse ano, todas com excelentes temas para desenvolvedores web!

Quanto aos screencasts, não esqueci deles não, falta o áudio, mas acontece que eu coloquei aparelho ortodôntico esse mês e falta me acostumar a falar melhor com eles. :)

Ah, Nando, valeu pela idéia do nome da palestra! ;)

Update: Aqui estão os slides da palestra: Git: Controle de Versões do jeito certo

É uma das features mais interessantes do Git. E até hoje, eu nunca tinha usado o bisect. Mas o que ele faz? De acordo com o próprio site: “Find the change that introduced a bug by binary search”. Interessante, não?

Como funciona?

O bisect ajuda a encontrar quando um bug foi introduzido no seu código, marcando pontos nos commits como ‘bons’ e ‘ruins’, e examinando commits intermediários usando um algoritmo de busca binária que vai eliminando metade dos commits cada vez que você marca um commit como ‘bom’ ou ‘ruim’.

Exemplo

Suponha que tenhamos um projeto com o seguinte log:

commit 7dd0f15d4e9a5fc1f625c0ac6e4788de45e0c40f
Author: Homer Simpson <homer@simpsons.com>
Date:   Wed May 21 17:36:27 2008 -0300

    Commit 20

commit dc358142a0deb6e1ba8e15f55f5e851e7bcc1ecf
Author: Homer Simpson <homer@simpsons.com>
Date:   Wed May 21 16:50:44 2008 -0300

    Commit 19

commit 648160ea61e194f97c8e11a35866025dca46c9a4
Author: Homer Simpson <homer@simpsons.com>
Date:   Wed May 21 16:34:38 2008 -0300

    Commit 18

commit 786a02663af9aa8eed533ab574b79294eddff4fc
Author: Homer Simpson <homer@simpsons.com>
Date:   Wed May 21 16:34:22 2008 -0300

    Commit 17

commit 9b76092b44f714d780a45e99532593da7b744801
Author: Homer Simpson <homer@simpsons.com>
Date:   Wed May 21 16:14:08 2008 -0300

    Commit 16

commit a00ef3d4e836af6777350a5f157132a255804e67
Author: Homer Simpson <homer@simpsons.com>
Date:   Wed May 21 11:33:45 2008 -0300

    Commit 15

commit 526be2a6b652df597e4d5b7670d58e7f0767e2e3
Author: Bart Simpson <bart@simpsons.com>
Date:   Wed May 21 11:30:50 2008 -0300

    Commit 14

commit 67022233899f78aee7f120337f1ec434d238f23f
Author: Homer Simpson <homer@simpsons.com>
Date:   Wed May 21 11:30:31 2008 -0300

    Commit 13

commit 21b8739f2ff271baa492d358e426ea1fc87bb7d7
Merge: ecc25a6... 00560d4...
Author: Homer Simpson <homer@simpsons.com>
Date:   Tue May 20 19:32:29 2008 -0300

    Commit 12

commit 00560d4b5ff1a2d463bfa19ba3d6346566db8e12
Author: Homer Simpson <homer@simpsons.com>
Date:   Tue May 20 17:11:56 2008 -0300

    Commit 11

Nós temos uma funcionalidade que funcionava no Commit 11, mas que no Commit 20 não funciona, porém, não sabemos em que momento este bug foi introduzido. Mentira, eu sei que foi o Bart quem introduziu o bug no Commit 14, mas vamos supor que nós não sabemos disso ainda! :)

E agora, o Git poderá nos socorrer?

Aqui é que entra o bisect.

$ git bisect start
$ git bisect bad
$ git bisect good 00560d4b5ff1a2d463bfa19ba3d6346566db8e12
Bisecting: 4 revisions left to test after this
[a00ef3d4e836af6777350a5f157132a255804e67] Commit 15

Nós dizemos ao git que o commit atual é ‘bad’. E que o Commit 11 estava ok (passando o hash identificador do Commit 11). Sendo assim, o Git escolhe um ponto intermediário entre os 2 commits, resultando no Commit 15.

Nós testamos o sistema, e vimos que o bug já estava presente nesta versão, assim, ou ele foi introduzido neste commit ou antes dele. Se o bug não estivesse presente nesta versão, significa que ele foi introduzido depois. De qualquer maneira, eliminaremos a necessidade de checar metade dos commits.

Vamos dizer ao git que esta versão é ‘bad’:

$ git bisect bad
Bisecting: 2 revisions left to test after this
[21b8739f2ff271baa492d358e426ea1fc87bb7d7] Commit 12
$

O Git nos leva até o Commit 12, nós analisamos novamente e o bug não estava presente nesta versão, então, podemos dizer que esta versão é ‘good’.

$ git bisect good
Bisecting: 1 revisions left to test after this
[526be2a6b652df597e4d5b7670d58e7f0767e2e3] Commit 14
$

Voltamos ao processo novamente e descobrimos que esta versão estava ‘bugada’.

$ git bisect bad
Bisecting: 0 revisions left to test after this
[67022233899f78aee7f120337f1ec434d238f23f] Commit 13

Agora, se esta versão estiver ok, o bug foi introduzido no Commit 14, visto que já dissemos que os commits 12 e 15 estavam ok. Testamos, e esta versão encontra-se ok.

$ git bisect good
526be2a6b652df597e4d5b7670d58e7f0767e2e3 is first bad commit
commit 526be2a6b652df597e4d5b7670d58e7f0767e2e3
Author: Bart Simpson <bart@simpsons.com>
Date:   Wed May 21 11:30:50 2008 -0300

    Commit 14

:040000 040000 58adb210b90786fb300ae1d0f3b478adbe643fb0 4adb482917754cb560e3f0f586c4a0739ebab373 M    file.rb

Sendo assim, o Git nos informa que o Commit 14 é o primeiro ‘bad’ commit e que o bug foi introduzido ali. Após ter encontrado o bug, rodamos:

$ git bisect reset

E agora, podemos corrigir o bug. E reclamar com o Bart que foi quem introduziu ele! :)

Neste caso, era um intervalo de apenas 10 commits, mas se fosse um intervalo maior, o bisect também ajudaria, visto que ele usa um algoritmo de busca binária.

É ou não é, sensacional? :)

Git – Compilando e Configurando

Você já deve ter ouvido falar do Subversion, não? E do Git? O Git é um sistema de controle de versões escrito por Linus Torvalds para controlar todo o código fonte do Kernel do Linux. Não vou explicar em maiores detalhes o que é o Git, para isso, procure no google.

Nesse screencast eu mostro como compilar o Git à partir do código fonte, configurá-lo e também mostro algumas funcionalidades bem básicas. Este é o primeiro Screencast de uma série sobre Git que eu pretendo fazer. Este primeiro é para iniciantes, mas também farei outros mais avançados com muitas dicas.

Download (43.6Mb, 7:47)