使用git bisect快速定位问题

我想大部分程序员都碰到过这样一件尴尬的事情，版本某天突然出现了一个莫名其妙的Bug，但是难以定位问题出在哪里。

在这样情况下，通常的做法是找到N天前的某个确定没有该Bug的版本，然后通过对比版本，来找到是哪一笔提交引发了这个问题，最后以这笔提交中的修改为线索来分析和解决问题。

这种方法存在一个问题，如果含有Bug的版本和正确的版本之前的有很多笔提交（如下图所示），那么每笔提交挨个确认会是一件很痛苦的事情。

熟悉算法的人应该很快就想到了，这种情况我们应该使用二分查找，git的开发者也想到了这一点，因此它提供了 bisect 命令来帮助我们快速进行版本比较。

bisect的主要思路是，首先启动一个查找，并让用户标记最早的不带bug的提交点（以下简称Good）和含有bug的提交点（以下简称Bad），这两点中间即使待查找的提交段，如下图中红色部分所示：

接下来，git会自动找到待查段正中间的提交点。

此时，我们针对这个提交点对应的版本进行测试，并根据测试结果，将这个提交标记为Good或者Bad。

标记完成后，我们就得到了新的待查找的段，git会自动找到新的待查段正中间的提交点，接下来我们继续对新的提交点进行验证，并标记。重复上面的过程，最终就能找到导致问题的那笔提交。

使用bisect进行问题查找主要依赖于下面的三个命令：

git bisect start
这个命令用来来启动一个查找，start后面可以加上good和bad的提交点，命令如下：
git bisect start [rev bad] [rev good]
如果不加good和bad的提交点，那么git将会等到我们使用good和bad命令指定对应的提交点后开始进行查找
git bisect good
用来标记一个提交点是正确的，后面可以加上rev来指定某个特定的提交点，如果不加，则默认标记当前的提交点。
git bisect bad
用来标记一个提交点是包含问题的，如果bad后可以加上rev来指定某个特定的提交点，如果不加，则默认标记当前的提交点。

使用bisect的流程如下

git bisect start 启动一个检查。
重复使用 git bisect good/bad 来标记git提供的提交点测试结果（正确/错误）直到找到出问题的提交点。
PS: 如果中途要退出本次查找，使用git bisect reset 退回到git bisect start执行前的状态。

bisect还有其他一些有用的命令

git bisect skip
跳过某一个待检查的提交点。有时因为种种原因（例如：该提交点无法单独运行或者我们确认该点没有问题等）我们需要跳过某些提交点，通过这个命令既可以达到这个目的。
git bisect reset
退出当前的检查，切换会git bisect start之前的分支
git bisect visualsize
启动gitk，查看当前的bisect状态
git bisect run
通过执行一个脚本来自动测试每个提交点，代替手工测试。脚本的返回值定义如下
- 0：Good
- 125：Skip
- 1~125，126，127：Failed