Git bisect: encontrar el commit que rompió tu aplicación
Publicado el 2026-10-26 por frfrand
Binary search for the change that introduced a production failure
Tu aplicación funcionaba hace dos semanas y ahora rompe al crear una reserva. Entraron cuarenta commits desde entonces. Revisarlos uno a uno es aburrido y lento; git bisect usa búsqueda binaria para encontrar el primero que introdujo el fallo.
La idea es usarlo para resolver un problema de verdad, no memorizar comandos porque quedan bien en una captura. Vamos con lo esencial, un ejemplo de trabajo y los errores que más conviene evitar.
Qué hace Git bisect y cuándo sirve
Marcás una revisión conocida como buena y otra como mala. Git te lleva automáticamente a un commit intermedio; lo probás y decís good o bad. Repetís hasta aislar un sospechoso. Cuanto más reproducible sea la prueba, más confiable será el resultado.
Si estás aprendiendo, probalo primero en un repositorio o entorno de prueba. Si administrás producción, documentá el estado antes de ejecutar nada que altere archivos, historial o datos. Eso te permite entender qué cambió y recuperarte si te equivocás.
Ejemplo para copiar y 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 resetNo copies la orden final sin mirar el estado previo. Los nombres de ramas, host, usuario o rutas son ejemplos; reemplazalos por los de tu proyecto. Algunos comandos modifican archivos o hacen peticiones que pueden escribir datos.
Cómo lo usaría paso a paso
- Paso 1. Reproduzca el error con un test o un procedimiento corto y repetible.
- Paso 2. Identifique un commit que falle y una versión anterior que sepa que funciona.
- Paso 3. Inicie bisect, marque ambas revisiones y pruebe el commit al que Git lo lleve.
- Paso 4. Marque cada revisión según el resultado; use
git bisect skipsi alguna no puede probarse. - Paso 5. Al encontrar el cambio sospechoso, vuelva a la rama original con
git bisect resety revise la causa.
Deténgase después de cada paso y compruebe el resultado. Si algo falla, anote el mensaje exacto antes de cambiar de estrategia. Saltar entre cinco soluciones aleatorias suele dificultar encontrar la causa real.
Un caso que podría pasarle trabajando con clientes
Una API FastAPI comenzó a duplicar reservas. Tiene un test que comprueba que dos peticiones simultáneas no creen la misma plaza. Con bisect encuentra en pocas pruebas la modificación que dejó de proteger esa operación.
El objetivo no es que «funcione una vez», sino que pueda explicar cómo lo repite sin comprometer otra aplicación. Si hay datos o credenciales de clientes, trabaje con pruebas separadas y accesos mínimos.
El error que más veo
Si el error depende de datos de producción o de una API externa inestable, la prueba puede dar resultados falsos. Prepare fixtures o mocks estables. No ejecute migraciones destructivas mientras bisect recorre commits antiguos.
Una regla sencilla: si no puedes explicar qué hará el comando sobre tu código o servidor, mira primero su ayuda oficial. Así evitarás confundir una solución rápida con un problema nuevo.
¿Dónde entra ArduMaker?
El hash de cada despliegue en ArduMaker puede ayudarte a delimitar cuándo empezó una incidencia. Recupera los logs y asocia el primer error a un rango de commits para acelerar el bisect.
Por ejemplo, puedes desplegar desde un repositorio Git a un VPS, asociar un dominio HTTPS y administrar servicios y bases desde el mismo entorno. El panel reduce tareas repetitivas de infraestructura, pero no reemplaza Git, las pruebas ni la revisión de permisos del proyecto.
Preguntas rápidas antes de aplicarlo
¿Esto cambia producción? Depende de dónde ejecutes la acción. Prueba localmente primero, identifica el commit o servicio afectado y prepara un plan de recuperación.
¿Cómo compruebo que salió bien? No te quedes con la ausencia de mensajes de error: revisa el estado, ejecuta un test funcional y comprueba los logs o el historial correspondiente.
¿Conviene automatizarlo? Si es repetible y tiene resultados verificables, sí. Pero la automatización debería fallar de forma clara y no esconder errores o credenciales.
Para ampliar
Resumen: la herramienta útil no es la que tiene más opciones, sino la que te permite entender qué cambió, comprobarlo y seguir trabajando sin sorpresas.