git bisect run 自动二等分
如果您的自动化./test脚本的退出状态为0（如果测试正常），则可以使用以下命令自动查找错误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
当然，这假设如果测试脚本./test是git跟踪的，那么在二等分过程中，它不会在更早的提交时消失。
我发现很多时候，您可以通过将树内脚本复制到树外并使用PATH-like变量并从那里运行来逃脱。
当然，如果test依赖的测试基础结构中断了较早的提交，则没有解决方案，您将必须手动进行操作，决定如何逐个测试提交。
但是我发现使用这种自动化通常可以工作，并且可以节省大量的时间，可以节省积压的任务中的较慢测试，您可以让它整夜运行，并且有可能在第二天早上发现错误，这是值得的尝试。
更多提示
在二等分之后停留在第一个失败的提交，而不是返回到master：
git bisect reset HEAD
start+初始bad并good一口气：
git bisect start KNOWN_BAD_COMMIT KNOWN_GOOD_COMMIT~
是相同的：
git checkout KNOWN_BAD_COMMIT
git bisect start
git bisect bad
git bisect good KNOWN_GOOD_COMMIT
查看到目前为止已经测试过的内容（通过手册good和bad或run）：
git bisect log
样本输出：
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
在git log上显示好坏参考以获得更好的时间观念：
git log --decorate --pretty=fuller --simplify-by-decoration master
这仅显示带有相应ref的提交，这将大大降低噪声，但确实包括类型为自动生成的ref：
refs/bisect/good*
refs/bisect/bad*
告诉我们哪些标记为好或坏的提交。
如果您想使用该命令，请考虑此测试仓库。
失败快，成功慢
有时：
- 失败很快发生，例如第一个测试中断
- 成功需要一段时间，例如失败的测试通过，以及我们不关心的所有其他测试
对于这些情况，例如，假设故障总是在5秒钟内发生，并且如果我们懒于按照我们的实际意愿更具体地进行测试，则可以按以下方式使用timeout：
#!/usr/bin/env bash
timeout 5 test-command
if [ $? -eq 1 ]; then
exit 1
fi
这是有效的，因为timeout退出124而test-command退出失败1。
魔术退出状态
git bisect run 对退出状态有些挑剔：
高于127的任何部分都会使二等分失败，并显示类似以下内容：
git bisect run failed:
exit code 134 from '../test -aa' is < 0 or >= 128
特别是，C assert(0)导致a SIGABRT并以状态134退出，这很烦人。
125是魔术，使得逃跑与git bisect skip。
这样做的目的是帮助避免由于不相关原因而导致的构建失败。
有关man git-bisect详细信息，请参见。
因此，您可能想要使用类似以下的内容：
#!/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"
在git 2.16.1上测试。