Git bisect —— 一种定位问题的方法

本周出现的一个混淆问题是一个比较难定位的问题，前后花了三个多小时，因此将定位问题方法分享一下。

当有些问题没有明显的报错，或者不好定位问题时（尤其是一些配置问题），我们希望尽快尽量缩小问题代码的查找范围，这样能够加快问题的定位。 git 的 bisect 子命令是使用二分查找的方式定位问题出现的节点。 bisect 的使用场景有一限制：

1. 之前某个节点不存在问题，现在出现了问题
2. 不确定是哪个节点引入的问题
3. bisect 只能缩小范围到某个节点，如果这个节点代码提交比较多，还是要分析代码来定位具体位置。

大家的都知道二分查找非常快，而使用此方法是慢在检测节点是否是好的还是坏的，比如安卓就需要安装app, 然后测试。不过好在二分查找的特性，也不需要测试太多节点。比如一列256个节点的提交，8次就能定位完成。平时我们大多数不会超过这个数量。

关于 bisect 的使用，在这里可以查看详细的使用步骤。

使用的一些发现：

1. 在 bisect 跳到某个节点时，可能需要改动一些代码，来测试该节点，修改后不必还原，也不必提交。git biset 跳到另一节点时，代码还在，除非你的修改恰好和跳到的节点冲突了。这是个很方便的特性，不用每次都还原，跳转，再次修改。

2. 在 git bisect reset 结束查找之间，如果有需要的代码记得复制保存，git bisect reset 会清空修改，回到最新的节点。

仅使用 bisect 能够定位节点，想要定位代码还需要定一个辅助命令。

在定位到问题节点之后，你可能想要知道这个节点都修改了哪些文件， git show 能帮你查看这个节点的所有修改。

 git show # 查看所有修改
 git show git show --stat # 修改的文件
 git show <节点> # 某节点的修改
 git show <文件名> # 仅显示当前节点的该文件修改

其他需要的指令可能就是 reset 和 checkout 检出文件来帮助恢复文件了。可以自行灵活运用。