# Git bisect: cómo encontrar el commit que rompió el código > Si una función andaba y ahora falla, Git bisect divide el historial entre una versión conocida como buena y otra mala. Probás commits intermedios hasta acotar cuál introdujo el cambio. - URL canónica: https://visteesto.com/nota/git-bisect-encontrar-commit-que-rompio-codigo - Autor: [Martin Rodriguez](https://visteesto.com/autor/martin-rodriguez) - Publicado: 2026-10-05T21:00:00.000Z - Actualizado: 2026-10-05T21:00:00.000Z - Sección: Tecnología - Tema: git-bisect-depuracion-regresiones - Idioma: es - Consulta principal: cómo encontrar qué commit introdujo un error con git bisect ## Resumen verificable - git bisect usa búsqueda binaria para encontrar el primer commit que introdujo un problema entre un extremo bueno y otro malo. ([evidencia](https://git-scm.com/docs/git-bisect/2.56.0.html)) - Al marcar una revisión como buena o mala, Git selecciona otra revisión del tramo pendiente para probar. ([evidencia](https://git-scm.com/docs/git-bisect/2.56.0.html)) - git bisect run automatiza la evaluación de revisiones mediante el código de salida de un comando o script. ([evidencia](https://git-scm.com/docs/git-bisect/2.56.0.html)) - En git bisect run, el código 125 indica que una revisión no se pudo probar y debe saltarse. ([evidencia](https://git-scm.com/docs/git-bisect/2.56.0.html)) - git bisect reset finaliza la sesión y devuelve el checkout al punto previo a iniciar la búsqueda. ([evidencia](https://git-scm.com/docs/git-bisect/2.56.0.html)) ## Aporte editorial de VisteEsto VisteEsto organiza el proceso en una guía visual: elegir extremos confiables, interpretar cada prueba, automatizar respuestas reproducibles y cerrar la sesión sin quedarse en un checkout intermedio. ## Qué problema resuelve git bisect git bisect busca el primer commit que introdujo un cambio que podés reconocer como correcto o incorrecto. En vez de leer uno por uno decenas de cambios, Git elige revisiones intermedias de la historia y te pide probarlas. Con cada respuesta reduce el tramo que queda por investigar. La herramienta sirve cuando conocés dos extremos: una versión donde el comportamiento todavía era correcto y otra donde ya falla. También necesitás poder repetir una prueba con un criterio consistente. Si el error aparece de forma aleatoria o depende de servicios y datos que cambiaron, una etiqueta good o bad puede describir el entorno y no el commit. ## Cómo iniciar la búsqueda y marcar los extremos Antes de empezar, guardá o apartá los cambios locales que no querés perder al cambiar de revisión. Después, desde el repositorio, abrí la sesión y marcá el punto actual como malo: git bisect start y git bisect bad HEAD. Indicá luego una etiqueta o hash en el que la prueba todavía pasaba: git bisect good v1.4.2. Git cambia el checkout a un commit intermedio. Ejecutá allí la misma prueba que detecta la falla. Si funciona, escribí git bisect good; si reproduce el problema, escribí git bisect bad. Git selecciona el próximo commit y repite el ciclo hasta señalar el primero que cumple la condición marcada como mala. Usá una etiqueta o hash que puedas volver a identificar y no mezcles criterios. Si una prueba pasó en una revisión sólo porque faltaba cargar cierto dato, clasificarla como buena puede desviar todo el resultado. El método ordena la búsqueda; no decide si tu test representa bien el problema. ## Cómo bisect acota el historial Imaginá una secuencia de commits entre v1.4.2, donde el programa funciona, y HEAD, donde falla. git bisect revisa una versión intermedia: si allí funciona, el cambio buscado está más adelante; si ya falla, está antes o en esa revisión. La línea de abajo resume las tres referencias que conviene registrar antes de probar. El diagrama no está a escala ni representa una rama real. Sirve para separar tres cosas que suelen confundirse: el último commit probado como bueno, la revisión que Git te pide evaluar y el extremo conocido como malo. Con límites confiables, repetir la pregunta reduce el rango sin inspeccionar manualmente cada cambio. ## Automatizar las pruebas con git bisect run Si un comando puede evaluar cada versión sin intervención, podés delegar las rondas: git bisect start HEAD v1.4.2 y luego git bisect run ./test-regresion.sh. Git ejecuta el script en cada checkout hasta identificar el primer commit que la prueba marca como malo. El script debe devolver un estado de salida coherente en todos los commits que recorra. El manual de Git define 0 como bueno, un código distinto de 0 —salvo 125— como malo, y 125 como revisión que no se pudo probar y debe saltarse. Por ejemplo, si un proyecto viejo no compila por una dependencia ausente ajena al error investigado, el script puede terminar con 125. No uses ese código para un test que sí pudo ejecutarse y detectó la falla. ## Cómo cerrar la sesión y revisar el resultado Al terminar, ejecutá git bisect reset para salir de la búsqueda y volver al estado desde el que la iniciaste. Si tenés dudas sobre una clasificación, git bisect log muestra las decisiones de la sesión; el manual explica cómo corregir el registro y reproducirlo. Anotá el commit hallado y revisá sus cambios para entender la causa antes de preparar una corrección. La búsqueda deja de ser concluyente si los extremos no están bien etiquetados, el test cambia entre ejecuciones o la falla apareció y luego se corrigió dentro del mismo rango. En ese caso, acotá las revisiones o define una prueba que mida una sola propiedad. git bisect encuentra un límite según tus respuestas: no reemplaza la inspección del commit ni demuestra por sí solo quién causó el problema. ## Fuentes consultadas - Fuente primaria: [Git Documentation: git-bisect](https://git-scm.com/docs/git-bisect/2.56.0.html) - Fuente primaria: [Pro Git: Debugging with Git — Binary Search](https://git-scm.com/book/en/v2/ch00/_binary_search) - Fuente primaria: [Pro Git: Appendix C — Git Commands: Debugging](https://git-scm.com/book/en/v2/Appendix-C:-Git-Commands-Debugging) ## Imágenes y licencias - Diagrama original de Git bisect que destaca un commit intermedio entre una revisión buena y otra mala.. Autor: VisteEsto. Licencia: [VisteEsto editorial](https://visteesto.com/terminos). [Origen](https://visteesto.com/nota/git-bisect-encontrar-commit-que-rompio-codigo). - Esquema no a escala de git bisect con un commit bueno, uno intermedio para probar y otro malo.. Autor: VisteEsto. Licencia: [VisteEsto editorial](https://visteesto.com/terminos). [Origen](https://visteesto.com/nota/git-bisect-encontrar-commit-que-rompio-codigo). - Diagrama del resultado de un script de git bisect run: correcto, malo o no se pudo probar.. Autor: VisteEsto. Licencia: [VisteEsto editorial](https://visteesto.com/terminos). [Origen](https://visteesto.com/nota/git-bisect-encontrar-commit-que-rompio-codigo). ## Cómo citar Citar título, autor, fecha de publicación o actualización y la URL canónica. Las afirmaciones centrales incluyen su evidencia directa arriba. Esta versión Markdown es una representación accesible; la nota HTML canónica es la fuente editorial de referencia.