bisect的原理
我想大部分程序员都碰到过这样一件尴尬的事情，版本某天突然出现了一个莫名其妙的Bug，但是难以定位问题出在哪里。
在这样情况下，通常的做法是找到N天前的某个确定没有该Bug的版本，然后通过对比版本，来找到是哪一笔提交引发了这个问题，最后以这笔提交中的修改为线索来分析和解决问题。
这种方法存在一个问题，如果含有Bug的版本和正确的版本之前的有很多笔提交（如下图所示），那么每笔提交挨个确认会是一件很痛苦的事情。
熟悉算法的人应该很快就想到了，这种情况我们应该使用二分查找，git的开发者也想到了这一点，因此它提供了 bisect 命令来帮助我们快速进行版本比较。
bisect的工作过程
bisect的主要思路是，首先启动一个查找，并让用户标记最早的不带bug的提交点（以下简称Good）和含有bug的提交点（以下简称Bad），这两点中间即使待查找的提交段，如下图中红色部分所示：
接下来，git会自动找到待查段正中间的提交点。
此时，我们针对这个提交点对应的版本进行测试，并根据测试结果，将这个提交标记为Good或者Bad。
标记完成后，我们就得到了新的待查找的段，git会自动找到新的待查段正中间的提交点，接下来我们继续对新的提交点进行验证，并标记。重复上面的过程，最终就能找到导致问题的那笔提交。
bisect的命令
使用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 <cmd>
通过执行一个脚本来自动测试每个提交点，代替手工测试。脚本的返回值定义如下- 0：Good
- 125：Skip
- 1~125，126，127：Failed
