Você sabe que os testes passavam na última release e falham agora. Use git bisect quando consegue repetir o mesmo teste nas duas pontas. O Git escolhe revisões intermediárias e elimina parte do intervalo conforme você informa se a falha aparece.

git bisect start
git bisect bad HEAD
git bisect good v1.2.0
# Teste a revisão que o Git selecionou e marque o resultado.
git bisect good
# Ao terminar, volte à revisão de partida.
git bisect reset

Confirme que v1.2.0 existe e realmente passa pelo teste. Se a revisão intermediária falhar pelo defeito investigado, use git bisect bad. Use git bisect skip quando ela não puder ser testada, por exemplo se uma dependência histórica deixou de estar disponível.

Se o teste for automatizável, git bisect run aceita um comando com código 0 para revisão boa e 125 para ignorar. Confira o diff do commit encontrado e reproduza o defeito no pai antes de preparar a correção.

Documentação de referência

Torne a verificação determinística

Antes de iniciar a busca, confirme que o comando tem o mesmo efeito em qualquer checkout. Fixe dependências e dados de teste, desative serviços instáveis e faça o script retornar um código diferente de zero somente quando encontra o defeito investigado. Se uma revisão não compila por uma razão alheia, retorne o código de skip previsto pelo Git em vez de chamá-la de ruim.

A busca pressupõe que há uma fronteira relativamente monotônica entre revisões boas e ruins. Uma regressão intermitente, um teste dependente de data ou várias mudanças independentes no intervalo podem tornar o resultado difícil de interpretar. Primeiro reduza o intervalo e confirme os commits de referência. Se o sintoma depende de uma feature flag, mantenha a mesma configuração durante a busca.

Revise o commit encontrado

O resultado identifica uma revisão que corresponde à transição observada, não necessariamente a única causa conceitual. Leia o diff, procure a mudança relacionada ao sintoma e rode o teste manualmente no commit e no pai. Depois que a investigação termina, git bisect reset retorna ao estado anterior à busca. Confira branch e árvore de trabalho antes de editar para não aplicar uma correção na revisão temporária.

Em um monorepo, o comando pode testar só o pacote afetado e economizar tempo, mas precisa manter a semântica do resultado. Escreva no log qual teste automatizado foi usado, quais revisions eram a boa e a ruim e quais foram ignoradas. Isso torna a conclusão reproduzível para a próxima pessoa.

Ao usar git bisect run, lembre que o código de saída 125 significa que a revisão não pôde ser classificada. Reserve esse resultado para casos realmente não testáveis, como uma dependência histórica indisponível. Se o script retornar 125 para qualquer falha, o Git vai ignorar inclusive o commit que contém a regressão. Registre os comandos e critérios do script para que outra pessoa consiga reproduzir a busca. Depois de encontrar a revisão, encerre bisect antes de criar commits para evitar registrar trabalho na árvore destacada.