git-bisect: en línea en la nube

PROGRAMA:

NOMBRE

git-bisect: use la búsqueda binaria para encontrar la confirmación que introdujo un error

SINOPSIS

git bisecar

DESCRIPCIÓN

El comando toma varios subcomandos y diferentes opciones según el subcomando:

git bisect start [--term- {antiguo, bueno} = --term- {nuevo, malo} = ]
[--no-checkout] [ [ ...]] [-] [ ...]
git bisect (malo | nuevo) [ ]
git bisect (bueno | viejo) [ ...]
términos de git bisect [--term-good | - término-malo]
git bisect saltar [( | ) ...]
git bisect reset [ ]
git bisect visualizar
repetición de git bisect
registro de bisección de git
git bisect ejecutar ...
ayuda de git bisect

Este comando usa un algoritmo de búsqueda binaria para encontrar qué confirmación en el historial de su proyecto
introdujo un error. Lo usa diciéndole primero una confirmación "incorrecta" que se sabe que contiene
el error, y una confirmación "buena" que se sabe que es antes de que se introdujera el error. Entonces git
bisect elige una confirmación entre esos dos puntos finales y le pregunta si la confirmación seleccionada
es "bueno" o "malo". Continúa reduciendo el rango hasta que encuentra la confirmación exacta
que introdujo el cambio.

De hecho, git bisect se puede usar para encontrar la confirmación que cambió cualquier propiedad de tu
proyecto; por ejemplo, la confirmación que corrigió un error, o la confirmación que causó un punto de referencia
rendimiento para mejorar. Para respaldar este uso más general, los términos "antiguo" y "nuevo" pueden
puede utilizarse en lugar de "bueno" y "malo", o puede elegir sus propios términos. Mira la sección
"Términos alternativos" a continuación para obtener más información.

Básico bisecar comandos: comienzo, malo, bueno
Como ejemplo, suponga que está tratando de encontrar la confirmación que rompió una característica que estaba
se sabe que funciona en la versión v2.6.13-rc2 de su proyecto. Comienzas una sesión bisectada como
manera:

$ git inicio bisect
$ git bisect bad # La versión actual es mala
$ git bisect good v2.6.13-rc2 # v2.6.13-rc2 es conocido por ser bueno

Una vez que haya especificado al menos una confirmación mala y una buena, git bisect selecciona una confirmación
en medio de ese rango de historial, lo verifica y genera algo similar a
el seguimiento:

Bisección: quedan 675 revisiones para probar después de esto (aproximadamente 10 pasos)

Ahora debería compilar la versión extraída y probarla. Si esa versión funciona
correctamente, escriba

$ git bisect bueno

Si esa versión está rota, escriba

$ bisecar mal

Entonces git bisect responderá con algo como

Bisección: quedan 337 revisiones para probar después de esto (aproximadamente 9 pasos)

Sigue repitiendo el proceso: compila el árbol, pruébalo y dependiendo de si es bueno
o mal ejecutar git bisect good o git bisect bad para solicitar la siguiente confirmación que necesita
pruebas.

Eventualmente, no quedarán más revisiones para inspeccionar, y el comando se imprimirá
una descripción del primer compromiso incorrecto. La referencia refs / bisect / bad se dejará apuntando
en ese compromiso.

Bisecar reajustar
Después de una sesión de bisección, para limpiar el estado de bisección y volver al HEAD original,
emita el siguiente comando:

$ git bisect restablecer

De forma predeterminada, esto devolverá su árbol a la confirmación que se comprobó antes de git
inicio bisecado. (Un nuevo inicio de git bisect también hará eso, ya que limpia la bisección anterior
Expresar.)

Con un argumento opcional, puede volver a una confirmación diferente en su lugar:

$ git bisect restablecer

Por ejemplo, git bisect reset bisect / bad comprobará la primera revisión incorrecta, mientras que git
bisect reset HEAD lo dejará en el compromiso de bisección actual y evitará el cambio
se compromete en absoluto.

Suplente términos
A veces no está buscando el compromiso que introdujo una rotura, sino más bien una
compromiso que provocó un cambio entre algún otro estado "antiguo" y "nuevo". Por ejemplo,
es posible que esté buscando la confirmación que introdujo una solución en particular. O podrías ser
buscando la primera confirmación en la que finalmente se convirtieron todos los nombres de archivo del código fuente
según el estándar de nomenclatura de su empresa. O lo que sea.

En tales casos, puede resultar muy confuso utilizar los términos "bueno" y "malo" para referirse a "la
estado antes del cambio "y" el estado después del cambio ". Por lo tanto, puedes usar el
términos "antiguo" y "nuevo", respectivamente, en lugar de "bueno" y "malo". (Pero ten en cuenta que
no se puede mezclar "bueno" y "malo" con "antiguo" y "nuevo" en una sola sesión).

En este uso más general, le proporcionas a git bisect una confirmación "nueva" que tiene alguna propiedad
y un compromiso "antiguo" que no tiene esa propiedad. Cada vez que git bisect comprueba un
commit, prueba si ese commit tiene la propiedad. Si es así, marque la confirmación como "nueva";
de lo contrario, márquelo como "antiguo". Cuando se realiza la bisección, git bisect informará qué
commit introdujo la propiedad.

Para usar "antiguo" y "nuevo" en lugar de "bueno" y malo, debes ejecutar git bisect start sin
confirma como argumento y luego ejecuta los siguientes comandos para agregar las confirmaciones:

git bisect old [ ]

para indicar que una confirmación fue anterior al cambio buscado, o

git bisect nuevo [ ...]

para indicar que fue después.

Para obtener un recordatorio de los términos utilizados actualmente, utilice

términos de git bisect

Puede obtener solo el término antiguo (respectivamente nuevo) con git bisect term --term-old o git
bisecar término - término-bueno.

Si desea utilizar sus propios términos en lugar de "malo" / "bueno" o "nuevo" / "antiguo", puede
elija los nombres que desee (excepto los subcomandos bisectables existentes como restablecer, iniciar, ...) por
comenzando la bisección usando

git bisect start --term-old - término-nuevo

Por ejemplo, si está buscando una confirmación que introdujo una regresión de rendimiento,
Puede usar

git bisect start --term-old rápido --term-new lento

O si está buscando la confirmación que solucionó un error, puede usar

git bisect start --term-new fixed --term-old roto

Luego, usa git bisect y git bisect en lugar de git bisect good y
git bisect bad para marcar confirmaciones.

Bisecar visualizar
Para ver a los sospechosos que quedan actualmente en gitk, emita el siguiente comando durante el
proceso de bisección:

$ git bisect visualizar

view también se puede utilizar como sinónimo de visualizar.

Si DISPLAY la variable de entorno no está configurada, git log se utiliza en su lugar. También puedes dar
opciones de línea de comandos como -p y --stat.

$ git vista bisectada --stat

Bisecar log y bisecar reproducir
Después de haber marcado las revisiones como buenas o malas, emita el siguiente comando para mostrar lo que ha
se ha hecho hasta ahora:

$ git bisectar registro

Si descubre que cometió un error al especificar el estado de una revisión, puede
guarde el resultado de este comando en un archivo, edítelo para eliminar las entradas incorrectas y
luego emita los siguientes comandos para volver a un estado corregido:

$ git bisect restablecer
$ git bisect reproducir ese archivo

Evitar las pruebas a hacer
Si, en medio de una sesión bisectada, sabe que la revisión sugerida no es una buena
uno para probar (por ejemplo, no se puede construir y usted sabe que el error no tiene nada
que ver con el error que está persiguiendo), puede seleccionar manualmente una confirmación cercana y probar que
uno en su lugar.

Por ejemplo:

$ git bisect bueno / malo # la ronda anterior fue buena o mala.
Bisección: quedan 337 revisiones para probar después de esto (aproximadamente 9 pasos)
$ git bisect visualiza # oops, eso no es interesante.
$ git reset --hard HEAD ~ 3 # intente 3 revisiones antes de lo que
# fue sugerido

Luego compile y pruebe la revisión elegida, y luego marque la revisión como buena o mala
de la manera habitual.

Bisecar omitir
En lugar de elegir una confirmación cercana por ti mismo, puedes pedirle a Git que lo haga por ti
emitiendo el comando:

$ git bisect skip # No se puede probar la versión actual

Sin embargo, si omite una confirmación adyacente a la que está buscando, Git no podrá
para saber exactamente cuál de esas confirmaciones fue la primera mala.

También puede omitir un rango de confirmaciones, en lugar de solo una, utilizando la notación de rango.
Por ejemplo:

$ git bisect omitir v2.5..v2.6

Esto le dice al proceso bisect que ninguna confirmación después de v2.5, hasta e incluyendo v2.6, debería
ser probado.

Tenga en cuenta que si también desea omitir la primera confirmación del rango, emitirá el
mando:

$ git bisect omitir v2.5 v2.5..v2.6

Esto le dice al proceso bisect que las confirmaciones entre v2.5 y v2.6 (inclusive) deben ser
omitido.

Corte DE INSCRIPCIÓN bisección by dando Saber más parámetros a bisecar comienzo
Puede reducir aún más el número de ensayos, si sabe qué parte del árbol está
involucrado en el problema que está rastreando, especificando parámetros de ruta al emitir
el comando bisect start:

$ git bisect start - arch / i386 incluyen / asm-i386

Si sabe de antemano más de una buena confirmación, puede reducir el espacio de bisección por
especificando todas las confirmaciones buenas inmediatamente después de la confirmación incorrecta al emitir el
comando de inicio bisecado:

$ git bisect iniciar v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 -
# v2.6.20-rc6 es malo
# v2.6.20-rc4 y v2.6.20-rc1 son buenos

Bisecar puedes seguir
Si tiene un script que puede indicar si el código fuente actual es bueno o malo, puede
bisect emitiendo el comando:

$ git bisect ejecutar my_script argumentos

Tenga en cuenta que el script (my_script en el ejemplo anterior) debería salir con el código 0 si el
el código fuente actual es bueno / antiguo y sale con un código entre 1 y 127 (inclusive),
excepto 125, si el código fuente actual es malo / nuevo.

Cualquier otro código de salida abortará el proceso de bisección. Cabe señalar que un programa que
termina vía exit (-1) deja $? = 255, (ver el salida(3) página de manual), ya que el valor es
picado con & 0377.

El código de salida especial 125 debe usarse cuando el código fuente actual no se puede probar. Si
el script sale con este código, se omitirá la revisión actual (ver git bisect skip
encima). 125 fue elegido como el valor más sensible a utilizar para este propósito, porque 126
y 127 son utilizados por los shells POSIX para señalar un estado de error específico (127 es para comando no
encontrado, 126 es para el comando encontrado pero no ejecutable; estos detalles no importan, ya que
son errores normales en el script, en lo que respecta a la ejecución bisecta).

A menudo puede encontrar que durante una sesión bisectada desea tener modificaciones temporales
(por ejemplo, s / # define DEBUG 0 / # define DEBUG 1 / en un archivo de encabezado, o "revisión que no tiene
esta confirmación necesita que se aplique este parche para solucionar otro problema, esta bisección no es
interesado en ") aplicado a la revisión que se está probando.

Para hacer frente a tal situación, después de la interna git bisecar encuentra la siguiente revisión para probar,
el script puede aplicar el parche antes de compilar, ejecutar la prueba real y luego decidir
si la revisión (posiblemente con el parche necesario) pasó la prueba y luego rebobinar el árbol
al estado prístino. Finalmente, el script debe salir con el estado de la prueba real para
deje que el ciclo de comando de ejecución de git bisect determine el resultado final de la sesión bisect.

OPCIONES

--no pago
No revise el nuevo árbol de trabajo en cada iteración del proceso de bisección.
En su lugar, actualice una referencia especial llamada BISECT_HEAD para que apunte a la
cometer que debería ser probado.

Esta opción puede ser útil cuando la prueba que realizaría en cada paso no
requieren un árbol verificado.

Si el repositorio está vacío, se asume --no-checkout.

EJEMPLOS

· Biseca automáticamente una compilación rota entre v1.2 y HEAD:

$ git bisect start HEAD v1.2 - # HEAD es malo, v1.2 es bueno
$ git bisect run make # "make" construye la aplicación
$ git bisect reset # salir de la sesión bisect

· Biseca automáticamente una falla de prueba entre el origen y HEAD:

$ git bisect start HEAD origin - # HEAD es malo, el origen es bueno
$ git bisect run make test # compilaciones y pruebas "make test"
$ git bisect reset # salir de la sesión bisect

· Biseca automáticamente un caso de prueba roto:

$ gato ~ / test.sh
#!/ Bin / sh
hacer || salida 125 # esto omite las compilaciones rotas
~ / check_test_case.sh # ¿Pasa el caso de prueba?
$ git bisect start HEAD HEAD ~ 10 - # culpable está entre los últimos 10
$ git bisect ejecutar ~ / test.sh
$ git bisect reset # salir de la sesión bisect

Aquí usamos un script personalizado test.sh. En este script, si make falla, omitimos el
compromiso actual. check_test_case.sh debe salir 0 si pasa el caso de prueba, y salir 1
de otra manera.

Es más seguro si tanto test.sh como check_test_case.sh están fuera del repositorio para
evitar interacciones entre los procesos de bisección, creación y prueba y los scripts.

· Biseca automáticamente con modificaciones temporales (hot-fix):

$ gato ~ / test.sh
#!/ Bin / sh

# modifique el árbol de trabajo fusionando la rama de hot-fix
# y luego intente una compilación
if git merge --no-commit hot-fix &&
“piensen de nuevo sobre los incrementos de precio”
y luego
# ejecutar una prueba específica del proyecto e informar su estado
~ / check_test_case.sh
estado = $?
más
# dígale a la persona que llama que esto no es comprobable
estado = 125
fi

# deshacer el ajuste para permitir un cambio limpio a la siguiente confirmación
git reset --difícil

# control de retorno
salir $ status

Esto aplica modificaciones de una rama de hot-fix antes de cada ejecución de prueba, por ejemplo, en caso de
su entorno de compilación o prueba cambió de modo que las revisiones anteriores pueden necesitar una corrección que
los más nuevos ya lo han hecho. (Asegúrese de que la rama de corrección rápida se base en una confirmación que sea
contenida en todas las revisiones que está dividiendo en dos, de modo que la combinación no atraiga
demasiado, o use git cherry-pick en lugar de git merge).

· Biseca automáticamente un caso de prueba roto:

$ git bisect start HEAD HEAD ~ 10 - # culpable está entre los últimos 10
$ git bisect ejecutar sh -c "hacer || salir 125; ~ / check_test_case.sh"
$ git bisect reset # salir de la sesión bisect

Esto muestra que puede prescindir de un script de ejecución si escribe la prueba en un solo
la línea.

· Localice una buena región del gráfico de objetos en un repositorio dañado

$ git bisect start HEAD [ ...] --no pago
$ git bisect ejecutar sh -c '
BUENO = $ (git for-each-ref "--format =% (objectname)" refs / bisect / good- *) &&
git rev-list --objects BISECT_HEAD --not $ GOOD> tmp. $$ &&
git pack-objects --stdout> / dev / null
rc = $?
rm -f tmp. $$
prueba $ rc = 0 '

$ git bisect reset # salir de la sesión bisect

En este caso, cuando git bisecar puedes seguir termina, bisect / bad se referirá a una confirmación que tiene
al menos un padre cuyo gráfico alcanzable es completamente transitable en el sentido requerido
by git paquete(s) objetos.

· Busque una solución en lugar de una regresión en el código

$ git inicio bisect
$ git bisect new HEAD # La confirmación actual está marcada como nueva
$ git bisect old HEAD ~ 10 # la décima confirmación a partir de ahora está marcada como antigua

o bien:

$ git bisect start --term-old roto --term-new fixed
$ git bisect arreglado
$ git bisect HEAD rota ~ 10

Encontrar ayuda
Utilice git bisect para obtener una breve descripción de uso y git bisect help o git bisect -h to
obtenga una descripción de uso larga.

Use git-bisect en línea usando los servicios de onworks.net