介绍 Git Bisect
"git bisect" 开始时可能有点令人困惑。一旦你理解了它的作用,就会变得容易。
"git bisect" 的典型场景是:刚刚发现了一个错误。你想找出是哪个版本引入了该错误。你知道该错误存在于最新的版本中,但它是在之前的版本中引入的。你需要一种方法来确定该错误是否存在。这可以是自动测试,也可以是手动运行的测试。
让我们开始吧。从你的分支中的最新版本开始,输入:
git bisect start
然后告诉 git 当前版本已知有问题:
git bisect bad
现在我们需要找到一个好的版本。检查一下是否有足够老的版本来避免这个错误。如果你认为32个版本之前应该是好的,那么:
git checkout HEAD~32
运行你的测试,看看是否有bug。如果有bug,你需要尝试一个更早的版本(只需再次输入“git checkout HEAD~32”)。一旦你找到一个没有bug的版本,那么:
git bisect good
这告诉Git当前版本是好的。Git会立即检出一个介于好的版本和坏的版本之间的修订版本;你会看到输出,例如:
$ git bisect good
Bisecting: 7 revisions left to test after this (roughly 3 steps)
[909ba8cd7698720d00b2d10738f6d970a8955be4] Added convenience delegators to Cache
运行你的测试,根据测试结果,执行以下命令之一:
- `git bisect good # 测试通过`
- `git bisect bad # 测试失败`
- `git bisect skip # 由于某些原因无法在此版本上运行测试(无法编译等)`
Git将继续切换到不同的版本,并且你会一直告诉它是好、坏还是跳过。当Git最终找出哪个版本引起了问题时,你会得到类似下面的结果:
b25ab3cee963f4738264c9c9b5a8d1a344a94623 is the first bad commit
commit b25ab3cee963f4738264c9c9b5a8d1a344a94623
Author: Wayne Conrad <wconrad@yagni.com>
Date: Fri Dec 25 18:20:54 2009 -0700
More tests and refactoring
:040000 040000 6ff7502d5828598af55c7517fd9626ba019b16aa 39f346cb5a289cdb0955fcbba552f40e704b7e65 M routecalc
而且你当前的版本将会在第一个错误提交上。
运行 git bisect "无需干预"
如果你的测试是自动化的,那么你可以让git完成所有的工作。按照上面开始的步骤做一切:
git bisect start
git bisect bad
git checkout HEAD~32
git bisect good
现在是时候展示一下魔法了。你只需要一个测试程序,成功时返回退出码"0",失败时返回1(例如)。告诉git关于你的测试:
git bisect run tests/mytest.rb
Git现在将运行测试,使用结果自动执行“git bisect good”或“git bisect bad”。它会一直进行下去,直到找到引入错误的提交。你只需要坐下来观察即可。
当你完成时,请执行:
git bisect reset
Git会把你带回起点。
good
和bad
的参数是什么?"bad" 提交是否是 "good" 提交的后代? - CB Baileygit bisect start
然后执行git bisect bad
或者git bisect good
后没有输出。无论我执行多少次git bisect good
或git bisect bad
,git bisect visualize
始终输出You need to give me at least one good and one bad revision. (You can use "git bisect bad" and "git bisect good" for that.)
。 - frediy