Git bisect: encontrar o commit que quebrou seu aplicativo
Publicado em 2026-10-26 por frfrand
Busca binária da alteração que introduziu uma falha em produção
Sua aplicação funcionava há duas semanas e agora quebra ao criar uma reserva. Entraram quarenta commits desde então. Revisá-los um a um é chato e lento; git bisect usa busca binária para encontrar o primeiro que introduziu a falha.
A ideia é usá-lo para resolver um problema de verdade, não memorizar comandos porque ficam bem em uma captura. Vamos com o essencial, um exemplo de trabalho e os erros que mais convém evitar.
O que o Git bisect faz e quando serve
Marcas uma revisão conhecida como boa e outra como ruim. O Git te leva automaticamente a um commit intermediário; você testa e diz good ou bad. Repete até isolar um suspeito. Quanto mais reproduzível for o teste, mais confiável será o resultado.
Se você está aprendendo, teste primeiro em um repositório ou ambiente de teste. Se administra produção, documente o estado antes de executar qualquer coisa que altere arquivos, histórico ou dados. Isso permite entender o que mudou e recuperar-se se errar.
Exemplo para copiar e entender
git bisect start
git bisect bad HEAD
git bisect good v1.3.0
# Ejecutar el test de la reserva
git bisect good # o: git bisect bad
# Al terminar
git bisect resetNão copie a ordem final sem olhar o estado prévio. Os nomes de branches, host, usuário ou caminhos são exemplos; substitua-os pelos do seu projeto. Alguns comandos modificam arquivos ou fazem requisições que podem gravar dados.
Como eu usaria passo a passo
- Passo 1. Reproduza o erro com um teste ou um procedimento curto e repetível.
- Passo 2. Identifique um commit que falha e uma versão anterior que você saiba que funciona.
- Passo 3. Inicie o bisect, marque ambas as revisões e teste o commit para o qual o Git o levar.
- Passo 4. Marque cada revisão de acordo com o resultado; use
git bisect skipse alguma não puder ser testada. - Passo 5. Ao encontrar a alteração suspeita, volte para o branch original com
git bisect resete revise a causa.
Pare após cada passo e verifique o resultado. Se algo falhar, anote a mensagem exata antes de mudar de estratégia. Pular entre cinco soluções aleatórias costuma dificultar encontrar a causa real.
Um caso que pode acontecer com você trabalhando com clientes
Uma API FastAPI começou a duplicar reservas. Você tem um teste que verifica que duas requisições simultâneas não criem a mesma vaga. Com o bisect, você encontra em poucos testes a modificação que deixou de proteger essa operação.
O objetivo não é que «funcione uma vez», mas que você possa explicar como repeti-lo sem comprometer outra aplicação. Se houver dados ou credenciais de clientes, trabalhe com testes separados e acessos mínimos.
O erro que mais vejo
Se o erro depender de dados de produção ou de uma API externa instável, o teste pode dar resultados falsos. Prepare fixtures ou mocks estáveis. Não execute migrações destrutivas enquanto o bisect percorre commits antigos.
Uma regra simples: se você não puder explicar o que o comando fará no seu código ou servidor, consulte primeiro a ajuda oficial. Assim, você evita confundir uma solução rápida com um novo problema.
Onde entra o ArduMaker?
O hash de cada implantação no ArduMaker pode ajudar a delimitar quando um incidente começou. Recupere os logs e associe o primeiro erro a um intervalo de commits para acelerar o bisect.
Por exemplo, você pode implantar de um repositório Git para um VPS, associar um domínio HTTPS e administrar serviços e bancos de dados no mesmo ambiente. O painel reduz tarefas repetitivas de infraestrutura, mas não substitui o Git, os testes nem a revisão de permissões do projeto.
Perguntas rápidas antes de aplicá-lo
Isso altera a produção? Depende de onde você executa a ação. Teste localmente primeiro, identifique o commit ou serviço afetado e prepare um plano de recuperação.
Como comprovar que deu certo? Não fique apenas com a ausência de mensagens de erro: verifique o status, execute um teste funcional e confira os logs ou o histórico correspondente.
Vale a pena automatizar? Se for repetível e tiver resultados verificáveis, sim. Mas a automação deve falhar de forma clara e não esconder erros ou credenciais.
Para ampliar
Resumo: a ferramenta útil não é a que tem mais opções, mas sim a que permite entender o que mudou, verificá-lo e continuar trabalhando sem surpresas.