Calculadora de Pasos Git Bisect | Estima las rondas y el tiempo para hallar una regresión
Antes de empezar una sesión de git bisect, conviene saber cuántas respuestas bueno/malo tendrás que dar. Introduce el número de commits y esta herramienta devuelve los pasos necesarios como ceil(log2(N)), un tiempo total estimado a partir de tu compilación por paso y una vista del rango que la búsqueda binaria va partiendo a la mitad.
💡 Sobre esta herramienta
git bisect ejecuta una búsqueda binaria entre un commit que sabes que funcionaba y otro que sabes que falla, aislando el commit culpable en tiempo O(log N). Entre 1000 commits, revisarlos uno a uno podría costar hasta 1000 compilaciones; la búsqueda binaria necesita solo unas 10.
La duda suele aparecer al principio: cuando la integración continua tarda varios minutos por ejecución, quieres saber si te esperan 7 rondas o 20 antes de comprometerte con la sesión. Esta calculadora deriva el número de pasos del rango de commits con ceil(log2(N)) y lo multiplica por tu tiempo de compilación por paso para estimar el total. Si ya sabes más o menos dónde están el último commit bueno y el primero malo, indica esas posiciones y el rango de búsqueda se reduce, bajando tanto los pasos como el tiempo. Es una forma rápida de ver cuánto compensa acotar el rango.
🧐 Preguntas Frecuentes
¿Cómo se calcula el número de pasos? Toma el número de commits del rango como N y devuelve ceil(log2(N)). Cada paso de bisect divide a la mitad el rango restante, así que ese es el número de divisiones necesarias para reducir N a un único commit. Cuando N es 1, el resultado es 0 pasos porque ya no queda nada que dividir.
¿Es obligatorio indicar las posiciones del commit bueno y el malo? No. Si las dejas vacías, la herramienta toma el commit bueno como el inicio del historial (0) y el malo como el más reciente (HEAD), usando el total de commits como rango. Al rellenarlas, la búsqueda se limita a ese intervalo, lo que reduce los pasos y el tiempo estimado.
¿Qué precisión tiene el tiempo estimado? Es una simple multiplicación del número de pasos por tu tiempo por paso. Introduce la duración media de tu compilación o prueba manual y obtienes una cifra aproximada; no incluye las esperas en cola de la integración continua ni las pausas y reanudaciones del bisect. Úsalo como una idea de la escala antes de empezar.
¿git bisect run cambia el número de rondas?
No. git bisect run <script> solo automatiza el veredicto bueno/malo de cada paso; la búsqueda binaria sigue haciendo las mismas divisiones. Tanto si respondes a mano como si deja que un script responda, la estimación de pasos se mantiene.
📚 Por qué la búsqueda binaria sigue siendo rápida
La palabra "bisect" significa cortar en dos. Partir el rango a la mitad en cada ronda reduce a la mitad los candidatos cada vez, así que llegar a un solo commit desde N solo cuesta "cuántas veces puedes dividir N entre 2 hasta llegar a 1": eso es log2(N). Duplicar el número de commits añade un único paso extra: unas 10 rondas para 1000 commits y cerca de 20 incluso para un millón. Ese crecimiento casi plano es justo lo que hace que bisect siga siendo práctico en repositorios enormes. Un matiz: los commits que no compilan pueden apartarse con git bisect skip, pero a medida que se acumulan los skip quedan menos divisiones limpias, por lo que el número real de rondas puede subir algo por encima del valor teórico.