git bisect的使用

git bisect

############# 学习内容源自精通Git ###############

话题引入：

作为新手，在做项目的时候难免会困难重重，但是只要抱着不畏困难、永攀高峰的精神以及耐心地去查找原因，困难就会不攻自破。由于刚使用git，虽然它很好用，但是自己不熟悉这个工具，即使知道里面的片面功能，也不能很好的使用，这也是自身需要克服的，想办法把去实现自己的思路。
问题是这样的，我在测试的时候发现目前的版本（最新拉取的版本）测试结果和昨天的结果不同，这时候为了不影响工作的速度，我想着是git reset到能得到正确结果的版本去测试，顺便还能找到出错的版本在哪里，这样也能为其他人解bug带来遍历。我在commit的序列中发现，我天呢，今天提交的版本怎么这么多，我不可能一个个去测试吧，这样的速度太慢了，这时候算法的知识就派到用场了，我使用的是二分查找法，既然我确信昨天的某个版本是正确的，那么错误的版本是从某个commit提交之后，查找的范围就是昨天的某本版本（good）到今天的某个版本（bad)，它们之间会有个分界线，查看这个版本提交的内容，大致判断是哪些代码改动造成的影响。 就这样，大概测试了四五个版本，就找到了那个影响测试结果的版本，这就体现了计算机知识与生活息息相关。但是我还是感觉有些繁琐，有没有更快的办法，让计算机自己去搜索问题的版本，抱着试试的态度，我就上了网上去查，果然网友们都经历过，而且还能熟练运用git的功能，让计算机去查找，很nice!下面我来总结一下git bisect的使用。

git bisect的使用

binary section 二分查找，故定义为git bisect
git bisect start //启动查找
git bisect bad //告诉系统当前我们所在的提交是有问题的
git bisect good v1.0 //告诉bisect已知的最后一次正常状态是哪次提交
Bisecting: 6 revisions left to test after this
[ecb6e1bc347ccecc5f9350d878ce677feb13d3b2] error handling on repo
git会发现你标记正常的提交v1.0与错误版本之间大约有12次提交，于是git就会检查出中间那个提交。现在我们可以测试这个版本，判断这个版本的错误是否还存在。如果错误还存在，那说明错误是这个版本之前引入的，如果不存在，那么说明是这个版本之后引入的。
假如这个版本的结果没有问题，那么输入：
git bisect good //告诉bisect这个版本是good的
这样会再产生一些结果：
Bisecting: 3 revisions left to test after this [b047b02ea83310a70fd603dc8cd7a6cd13d15c04] secure this thing
假如这个版本是有问题的，那么输入：
git bisect bad //告诉bisect这个版本是bad的
Bisecting: 1 revisions left to test after this [f71ce38690acf49c1f3c9bea38e09d82a5ce6014] drop exceptions table
这个提交是正常的，现在git拥有的信息已经确定引入问题的位置在哪里。它会告诉你第一个错误提交的SHA-1值并显示一些提交说明，以及哪些文件在那次提交里修过，这样便可以找到引入BUG的根源：
$ git bisect good
b047b02ea83310a70fd603dc8cd7a6cd13d15c04 is first bad commit commit b047b02ea83310a70fd603dc8cd7a6cd13d15c04 Author: PJ Hyett <pjhyett@example.com> Date: Tue Jan 27 14:48:32 2009 -0800 secure this thing :040000 040000 40ee3e7821b895e52c1695092db9bdc4c61d1730 f24d3c6ebcfc639b1a3814550e62d60b8e68a8e4 M config
当我们完成这些操作之后，我们应该执行git bisect reset重置我们的HEAD指针到开始的位置，否则便会停留在一个很奇怪的状态：
git bisect reset
这样我们便可以在几分钟内从数百个提交中找到BUG，希望此次的分享能够帮助到大家。