业务场景

某一天，业务部门反馈说系统某个功能现在不能用了，之前还是能用的，你有点诧异，随即在开发环境一测，果然如此。此时你一定在想到底咋回事？是代码被其他同事合并分支时处理了？是某位同事出于某种原因做了特殊处理？还是各种其他的原因呢？总之就是很想知道到底是什么时候什么人做了什么是导致的功能错误！

简介

碰到上面的情况，你就可以使用 git bisect 命令来快速定位问题发生在那一次代码提交。

git bisect是一个很有用的命令，用来查找哪一次代码提交引入了错误！知道了那一次的提交导致了错误，也就知道了什么时间什么人提交了什么导致的错误！

它的原理很简单，就是将代码提交的历史，按照两分法不断缩小定位。所谓"两分法"，就是将代码历史一分为二，确定问题出在前半部分，还是后半部分，不断执行这个过程，直到范围缩小到某一次代码提交。

使用它的方法是，首先告诉它一个已知包含 bug 的“ bad”提交，以及一个已知包含 bug 的“ good”提交。然后 git bisect 在这两个端点之间选择一个提交，并询问您所选择的提交是“好”还是“坏”。以此类推不断的缩小范围，直到找到引入更改的确切提交。

如何使用

1，查看历史提交记录

$ git log --pretty=oneline

上图中的提交记录，是git log配置别名后，更形象的一种展示方式，只用git log --pretty=oneline后也能显示提交历史记录，但是显示不够形象。

2，查询导致错误的提交

2.1 启动查错

查找 最近提交的commitID 与 查找范围起点的commitID 之间的提交历史，作为查错范围。

$ git bisect start [最近提交的commitID] [查找范围起点的commitID]

具体执行命令：

$ git bisect start HEAD 4d83cf

执行上面的命令后项目代码就会切换到这段提交历史范围中间的那个提交上。此时再次测试功能点，看此时是否正常？

2.2 查错过程

如果测试功能正常，则说明当前所在的提交（提交历史最中间的这一次提交）是正确的，既然中间的提交没问题，说明错误应该是出现在提交历史的后半段，此时需要执行下面的命令来标识当前所在的提交（提交历史最中间的这一次提交）是正确的，同时会自动切换到后半段提交历史的中间提交上。

$ git bisect good

此时，再次测试功能点是否正确，如果错误，则说明当前所在的提交已经是错误的，使用下面的命令标识当前所在的提交是错误的，同时会自动切换到错误范围的中间提交上。

$ git bisect bad

不断重复上面的过程，直到成功查找到导致问题的那一次提交。此时Git 会给出如下的提示

213f332de08dc311b2f901d47f5c738fa9ebeecc is the first bad commit

查到了错误由那个提交导致后，可以查约代码，确定错误的具体原因，方便后续修复。

3，退出查询错误（bisect）并返回到原来的 HEAD

$ git bisect reset

默认情况下，这将把您的树返回到 git bisect 启动之前签出的提交。当然你也可以返回到另外一个提交位置比如：

$ git bisect reset <commit>

全过程如下图：

4，解决问题

此时你已经了解了 什么时间、提交人、提交了什么代码 这些关键要素，接下来就是修复代码，再次提交解决bug了。至于提交人为啥提交了这些代码，可以与提交人简单沟通下确保了解他的真实意图，不要出现误解！

总结

上面只是用到了bisect一些基础命令，更丰富的使用技巧请参考：git bisect，或运行下面命令查看：

$ git bisect --h