Buscar..


Sintaxis

  • git bisect <subcommand> <options>

  • git bisect start <bad> [<good>...]

  • git bisect reset

  • git bisect good

  • git bisect bad

Búsqueda binaria (git bisect)

git bisect permite encontrar qué cometer introdujo un error utilizando una búsqueda binaria.

Empiece por dividir una sesión proporcionando dos referencias de confirmación: una buena confirmación antes del error y una mala confirmación después del error. En general, el mal cometido es HEAD .

# start the git bisect session
$ git bisect start

# give a commit where the bug doesn't exist
$ git bisect good 49c747d

# give a commit where the bug exist
$ git bisect bad HEAD

git inicia una búsqueda binaria: divide la revisión a la mitad y cambia el repositorio a la revisión intermedia. Inspeccione el código para determinar si la revisión es buena o mala:

# tell git the revision is good,
# which means it doesn't contain the bug
$ git bisect good

# if the revision contains the bug,
# then tell git it's bad
$ git bisect bad

git continuará ejecutando la búsqueda binaria en cada subconjunto restante de revisiones incorrectas según sus instrucciones. git presentará una única revisión que, a menos que sus banderas sean incorrectas, representará exactamente la revisión donde se introdujo el error.

Después, recuerde ejecutar git bisect reset para finalizar la sesión bisect y volver a HEAD.

$ git bisect reset

Si tiene un script que puede verificar el error, puede automatizar el proceso con:

$ git bisect run [script] [arguments]

Donde [script] es la ruta a su script y [arguments] es cualquier argumento que se debe pasar a su script.

La ejecución de este comando ejecutará automáticamente la búsqueda binaria, ejecutando git bisect good o git bisect bad en cada paso, dependiendo del código de salida de su script. Salir con 0 indica que es good , mientras que salir con 1-124, 126 o 127 indica que es malo. 125 indica que el script no puede probar esa revisión (lo que activará un git bisect skip ).

Semiautomáticamente encontrar un cometido defectuoso.

Imagina que estás en la rama master y que algo no está funcionando como se esperaba (se introdujo una regresión), pero no sabes dónde. Todo lo que sabe es que estaba trabajando en la última versión (que fue, por ejemplo, etiquetada o que conoce el hash de confirmación, tomemos el old-rel aquí).

Git tiene ayuda para usted, encontrando la confirmación defectuosa que introdujo la regresión con un número muy bajo de pasos (búsqueda binaria).

En primer lugar empezar a dividir:

git bisect start master old-rel

Esto le dirá a git que el master es una revisión rota (o la primera versión rota) y old-rel es la última versión conocida.

Git ahora verificará una cabeza separada en medio de ambas confirmaciones. Ahora, puedes hacer tus pruebas. Dependiendo de si funciona o no problema

git bisect good

o

git bisect bad

. En caso de que este compromiso no se pueda probar, puede fácilmente git reset y probarlo, git se encargará de esto.

Después de unos pocos pasos, git producirá el hash de confirmación defectuoso.

Para abortar el proceso de bisecta solo emita

git bisect reset

y git restaurará el estado anterior.



Modified text is an extract of the original Stack Overflow Documentation
Licenciado bajo CC BY-SA 3.0
No afiliado a Stack Overflow