git bisect run bisección automática
Si tiene un ./testscript automatizado que tiene el estado de salida 0 si la prueba es correcta, puede encontrar automáticamente el error con bisect run:
git checkout KNOWN_BAD_COMMIT
git bisect start
# Confirm that our test script is correct, and fails on the bad commit.
./test
# Should output != 0.
echo $?
# Tell Git that the current commit is bad.
git bisect bad
# Same for a known good commit in the past.
git checkout KNOWN_GOOD_COMMIT
./test
# Should output 0.
echo $?
# After this, git automatically checks out to the commit
# in the middle of KNOWN_BAD_COMMIT and KNOWN_GOOD_COMMIT.
git bisect good
# Bisect automatically all the way to the first bad or last good rev.
git bisect run ./test
# End the bisect operation and checkout to master again.
git bisect reset
Esto supone, por supuesto, que si el script de prueba ./testes rastreado, no desaparece en algún commit anterior durante la bisección.
He descubierto que muy a menudo puedes escapar simplemente copiando el script del árbol fuera del árbol, y posiblemente jugando con PATHvariables similares, y ejecutándolo desde allí.
Por supuesto, si la infraestructura de prueba de la que testdepende se rompe con los commits más antiguos, entonces no hay solución, y tendrá que hacer las cosas manualmente, decidiendo cómo probar los commits uno por uno.
Sin embargo, he descubierto que el uso de esta automatización a menudo funciona, y puede ser un gran ahorro de tiempo para las pruebas más lentas que se encuentran en su cartera de tareas, donde puede dejar que se ejecute durante la noche y posiblemente identificar su error a la mañana siguiente, vale la pena. el intento
Mas consejos
Manténgase en la primera confirmación fallida después de la bisección en lugar de volver a master:
git bisect reset HEAD
start+ inicial bady goodde una vez:
git bisect start KNOWN_BAD_COMMIT KNOWN_GOOD_COMMIT~
es lo mismo que:
git checkout KNOWN_BAD_COMMIT
git bisect start
git bisect bad
git bisect good KNOWN_GOOD_COMMIT
Vea lo que se ha probado hasta ahora (por manual goody / bado run):
git bisect log
Salida de muestra:
git bisect log
git bisect start
# bad: [00b9fcdbe7e7d2579f212b51342f4d605e53253d] 9
git bisect bad 00b9fcdbe7e7d2579f212b51342f4d605e53253d
# good: [db7ec3d602db2d994fe981c0da55b7b85ca62566] 0
git bisect good db7ec3d602db2d994fe981c0da55b7b85ca62566
# good: [2461cd8ce8d3d1367ddb036c8f715c7b896397a5] 4
git bisect good 2461cd8ce8d3d1367ddb036c8f715c7b896397a5
# good: [8fbab5a3b44fd469a2da3830dac5c4c1358a87a0] 6
git bisect good 8fbab5a3b44fd469a2da3830dac5c4c1358a87a0
# bad: [dd2c05e71c246f9bcbd2fbe81deabf826c54be23] 8
git bisect bad dd2c05e71c246f9bcbd2fbe81deabf826c54be23
# bad: [c536b1b7242d5fcf92cd87e9a534bedb1c0c9c05] 7
git bisect bad c536b1b7242d5fcf92cd87e9a534bedb1c0c9c05
# first bad commit: [c536b1b7242d5fcf92cd87e9a534bedb1c0c9c0
Muestre referencias buenas y malas en git log para obtener una mejor noción del tiempo:
git log --decorate --pretty=fuller --simplify-by-decoration master
Esto solo muestra confirmaciones con una referencia correspondiente, lo que reduce el ruido real, pero incluye referencias de tipo autogeneradas:
refs/bisect/good*
refs/bisect/bad*
que nos dicen qué compromisos hemos marcado como buenos o malos.
Considera este repositorio de prueba si quieres jugar con el comando.
El fracaso es rápido, el éxito es lento
Algunas veces:
- la falla ocurre rápido, por ejemplo, una de las primeras pruebas se rompe
- el éxito lleva un tiempo, p. ej., la prueba rota pasa, y todas las demás pruebas que no nos interesan siguen
Para esos casos, por ejemplo, suponiendo que la falla siempre ocurre dentro de 5 segundos, y si somos flojos para hacer la prueba más específica como realmente deberíamos, podemos usarla timeoutcomo en:
#!/usr/bin/env bash
timeout 5 test-command
if [ $? -eq 1 ]; then
exit 1
fi
Esto funciona desde las timeoutsalidas 124mientras que la falla de las test-commandsalidas 1.
Estados de salida mágica
git bisect run es un poco exigente con los estados de salida:
cualquier cosa por encima de 127 hace que la bisección falle con algo como:
git bisect run failed:
exit code 134 from '../test -aa' is < 0 or >= 128
En particular, una C assert(0)conduce a SIGABRTay sale con el estado 134, muy molesto.
125 es mágico y hace que se salte la carrera git bisect skip.
La intención de esto es ayudar a omitir compilaciones rotas debido a razones no relacionadas.
Ver man git-bisectpara los detalles.
Por lo tanto, es posible que desee utilizar algo como:
#!/usr/bin/env bash
set -eu
./build
status=0
./actual-test-command || status=$?
if [ "$status" -eq 125 ] || [ "$status" -gt 127 ]; then
status=1
fi
exit "$status"
Probado en git 2.16.1.