git二分法查找命令的使用

        啰嗦下：发现自己的blog被转载了，不过没有注明出处，有点痛并快乐着的感觉。这里正式申明下：转载请注明出处，感谢。如有商用目的请务必只会本人。

 

        这周四我们版本某个模块出现了一个严重问题，查了一下之后发现在之前的几个版本是没有这个问题，是正常的。毫无疑问：这是我们自己修改引入的。接下来的工作就是在最近的提交记录中找出引入问题的提交。
        去年这个时候，本人刚接触Git不久，当时遇到这种问题都是使用在Git基础上人工手动操作的二分法：多次利用git branch [commitID] [branchName]建立不同的分支。选取一个没有问题的历史提交，在其和当前提交中选取一个中间提交，建立头结点指向这个提交的分支。之后在此基础上在找其中间的提交，直到找到引入问题的提交。或者直接一点直接当做一个google原生bug去修改。
        由于自己懒又怕麻烦不愿学习，这个土方法我用了有一段时间。这种查找方式有很多缺陷：1.每次你都得执行git branch [commitID] [branchName]建立新的分支；2.你的本地仓库下面出现了很多分支（建议问题解决之后删除）；3.你得每次自己找提交节点，这个很容易搞混淆。后来我们发现可以使用git checkout 直接修改当前头结点的指向，不用每次建立分支，但是这个方法不推荐，git checkout 切换头结点指向的命令还是少用比较好。
        现在我们介绍一个非常强大非常给力的武器：git bisect，git提供的基于二分法高效查找工具。因为我们一般都是在出问题的提交节点开始找，这样的话你就可以在当前提交节点执行下面两个命令：
        git bisect start（开始使用git bisect命令）
        git bisect bad commitID（标记有问题的节点，如果不加commitID，则默认使用当前节点为问题节点）
然后找出最近一个正确版本的记录，基于此版本的commitID执行下面的命令
        git bisect good commitID
        接下来git就会告诉你它已经选取了一个中间提交节点，你可以编译测试了。如果仍然有问题就执行git bisect bad ，如果发现没有问题就执行git bisect good。重复前面的操作，git会自动查找中间提交节点，并且指向这个提交。
        当你找到出问题的提交节点时候，git就会有如下提示：
        commitID  is first bad commit
        ……
        查看完代码之后，可以使用git bisect resect来恢复查找之前的状态。当然你也可以直接使用这个命令恢复到正常，在使用git show commitID来产看出问题的提交节点。