Calculadora de Passos do Git Bisect | Estime as rodadas e o tempo para achar uma regressão

Antes de iniciar uma sessão de git bisect, ajuda saber quantas respostas bom/ruim você terá que dar. Digite o número de commits e esta ferramenta retorna os passos necessários como ceil(log2(N)), um tempo total estimado a partir da sua build por passo e uma visão do intervalo que a busca binária vai dividindo ao meio.

💡 Sobre esta ferramenta

O git bisect executa uma busca binária entre um commit que você sabe que funcionava e outro que você sabe que falha, isolando o commit culpado em tempo O(log N). Em 1000 commits, conferir um por um poderia custar até 1000 builds; a busca binária precisa de apenas cerca de 10.

O atrito costuma estar no começo: quando a integração contínua leva vários minutos por execução, você quer saber se vai encarar 7 rodadas ou 20 antes de se comprometer com a sessão. Esta calculadora deriva o número de passos do intervalo de commits com ceil(log2(N)) e o multiplica pelo seu tempo de build por passo para estimar o total. Se você já sabe mais ou menos onde ficam o último commit bom e o primeiro com falha, informe essas posições e o intervalo de busca encolhe, reduzindo tanto os passos quanto o tempo. É uma forma rápida de ver o quanto estreitar o intervalo realmente compensa.

🧐 Perguntas frequentes

Como o número de passos é calculado? Ele toma o número de commits do intervalo como N e retorna ceil(log2(N)). Cada passo do bisect divide o intervalo restante ao meio, então esse é o número de divisões necessárias para reduzir N a um único commit. Quando N é 1, o resultado é 0 passos porque não sobra nada para dividir.

Preciso informar as posições do commit bom e do com falha? Não. Deixe-as vazias e a ferramenta considera o commit bom como o início do histórico (0) e o com falha como o mais recente (HEAD), usando o total de commits como intervalo. Ao preenchê-las, a busca fica limitada a esse trecho, o que reduz os passos e o tempo estimado.

Qual é a precisão do tempo estimado? É uma simples multiplicação do número de passos pelo seu tempo por passo. Informe a duração média da sua build ou do teste manual e você obtém um valor aproximado; ele não considera as esperas na fila da integração contínua nem as pausas e retomadas do bisect. Use-o como uma noção de escala antes de começar.

O git bisect run muda o número de rodadas? Não. O git bisect run <script> apenas automatiza o veredito bom/ruim de cada passo; a busca binária ainda faz o mesmo número de divisões. Quer você responda manualmente, quer deixe um script responder, a estimativa de passos se mantém.

📚 Por que a busca binária continua rápida

A palavra "bisect" significa cortar em dois. Dividir o intervalo ao meio a cada rodada reduz os candidatos pela metade toda vez, então chegar a um único commit a partir de N custa apenas "quantas vezes dá para dividir N por 2 até chegar a 1": isso é log2(N). Dobrar o número de commits acrescenta só um passo extra: cerca de 10 rodadas para 1000 commits e perto de 20 mesmo para um milhão. Esse crescimento quase plano é exatamente o que mantém o bisect prático em repositórios enormes. Uma ressalva: commits que não compilam podem ser deixados de lado com git bisect skip, mas conforme os skips se acumulam, sobram menos divisões limpas, então a contagem real de rodadas pode ficar um pouco acima do valor teórico.