最后一步，这次是坏的。 $ git bisect bad 458eab0eb8d808e16d98ec7039a7c53855dd9ed6 is the first bad commit commit 458eab0eb8d808e16d98ec7039a7c53855dd9ed6 Author: Rodrigo Flores <mail@rodrigoflores.org> Date: Tue Oct 21 22:31:05 2014 -0200 added 1013 :100644 100644 7bc3db7f48a43ccf1a8cc7c26146912cc88c1009 b393a2138a96c1530f41f70 1ab43cca893226976 M file.txt 我们终于得到了那个引入 1013 数字的提交点。命令 git bisect log 可以回放整个过程。 $ git bisect start # bad: [740cdf012013dc41a39b41d4b09b57a970bfe38f] added 1024 git bisect bad 740cdf012013dc41a39b41d4b09b57a970bfe38f # good: [7c0dcfa7514379151e0d83ffbf805850d2093538] added 1 git bisect good 7c0dcfa7514379151e0d83ffbf805850d2093538 # good: [8950f7db7e7cad0b2dc394ff9b75fc3d38c9d72a] added 512 git bisect good 8950f7db7e7cad0b2dc394ff9b75fc3d38c9d72a # good: [a01ba83f3500b48da97c5f5c33052623aaa4161a] added 768 git bisect good a01ba83f3500b48da97c5f5c33052623aaa4161a # good: [4a4a668bf3363d09af5fd1906bc4272aacdb4495] added 896 git bisect good 4a4a668bf3363d09af5fd1906bc4272aacdb4495 # good: [9059c5b8b898159e8d1d797bff3b1febd1fd6a1c] added 960 git bisect good 9059c5b8b898159e8d1d797bff3b1febd1fd6a1c # good: [0c844d0b33ef297b742206ebc293f4925705b083] added 992 git bisect good 0c844d0b33ef297b742206ebc293f4925705b083 # good: [0ee17eb17bd96b321a01c73eb13a8929a68b1239] added 1008 git bisect good 0ee17eb17bd96b321a01c73eb13a8929a68b1239 # bad: [dfb1e71736dcfffa2a30aecd7299f45f757c057e] added 1016 git bisect bad dfb1e71736dcfffa2a30aecd7299f45f757c057e # good: [6e6d08c374df5162fed65fed82859b69f86b936e] added 1012 git bisect good 6e6d08c374df5162fed65fed82859b69f86b936e # bad: [1d23b7045a8accd254efa859d7fc66f1f58a59f0] added 1014 git bisect bad 1d23b7045a8accd254efa859d7fc66f1f58a59f0 # bad: [458eab0eb8d808e16d98ec7039a7c53855dd9ed6] added 1013 git bisect bad 458eab0eb8d808e16d98ec7039a7c53855dd9ed6 # first bad commit: [458eab0eb8d808e16d98ec7039a7c53855dd9ed6] added 1013 这个例子里一共有 1024 个提交点，遍历他们我们只用了 10 步。如果提交点数量再多一倍变成 2048 个，根据二分查找算法，我们仅仅需要多加一步就能找到想要的提交点，因为二分查找算法的时间复杂度为 O(log n)。 自动化Git bisect 能接受一个脚本文件名作为命令参数，通过它的返回代码判断当前提交点的好坏。如果返回 0，就是好的提交点，返回其他值就是坏的提交点。凑巧的是，grep 命令如果找到了匹配行就会返回 0，反之返回 1。你可以使用 echo $? 命令来检查测试命令的返回值。 grep 的返回值正好和我们的测试标准相反，所以我们需要写一个脚本来反转它的值（我不太习惯写 shell 脚本，如果大家有更好的方法，感谢告知）。
保存上述代码为 test.sh，并赋予它执行权限。 接着在给 bisect 命令指定了初始的好/坏提交点之后，你只需要运行：
不费吹灰之力，你就得到了出问题的提交点。 结论你很可能不会每天都用到 bisect。也许一周用一次，甚至一个月只用到一次。但是当你想要排查出带入问题的提交点时，bisect 确实能帮你一把。尽管并非必须，控制好每次提交的改动规模不要太大将对 bisect 排查大有帮助。如果每个提交都包含了大量的改动，那么就算 bisect 帮你找到这个提交，你也不得不埋头于大量的改动中苦苦搜寻 bug 的踪迹。因此，我推荐的提交策略是嫌大不嫌多。 你呢？你经常使用 bisect 吗？ |
