git bisect: encontrar o commit que partiu tudo

Funcionava no mês passado, está partido hoje, e pelo meio há duzentos commits. A forma manual de encontrar o culpado é ir recuando e experimentando — e são duzentas tentativas no pior caso.

O git bisect faz uma busca binária pelo histórico: com duzentos commits, encontra-o em oito tentativas.

1. À mão

git bisect start

# O sítio onde está partido
git bisect bad

# Um sítio onde se sabe que funcionava
git bisect good v1.4.0

O Git salta para o meio do intervalo e deixa-nos lá. Experimenta-se, e responde-se:

git bisect good   # este ainda estava bom
git bisect bad    # este já estava partido

De cada vez, metade do histórico desaparece da lista de suspeitos. No fim, o Git escreve qual é o commit e mostra-o.

git bisect reset  # voltar ao sítio onde se estava

2. Automático, que é onde brilha

Se a falha se puder verificar por um comando, o Git faz tudo sozinho. O que interessa é o código de saída: zero é bom, diferente de zero é mau.

git bisect start HEAD v1.4.0
git bisect run npm test -- src/server/sanitizar.test.ts

E vai-se tomar um café. No fim aparece a linha que interessa:

a3f9c21 is the first bad commit

3. Dois conselhos que fazem a diferença

• Escreva primeiro o teste que falha. Um comando que reproduz a falha em segundos transforma a caça de uma tarde numa de dois minutos — e fica no repositório a impedir a reincidência.

• Commits pequenos pagam-se aqui. O bisect aponta um commit; se esse commit mudou quarenta ficheiros, ainda falta a parte difícil. Se mudou três linhas, acabou.

Para commits que não compilam pelo meio — acontece — há o git bisect skip, que os põe de lado sem estragar a busca.