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,希望此次的分享能够帮助到大家。