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来产看出问题的提交节点。


      


        

你可能感兴趣的:(二分查找,git,git,二分法,git调试)