二分

大家好，我是 lucifer。明天给大家分享我的日常工作中罕用的 debug 杀器！ 二分代码当我发现一个难以了解和发现的 bug 的时候，我的终极方法就是二分代码。 比方先删去文件 a 的一半代码（大概），而后测试问题是否还在。 如果问题不在了，那么咱们就找到了出问题的代码。如果问题还在，那么咱们持续应用同样的方法，持续删去文件 a 的一半代码（大概），而后测试问题是否还在。反复上述步骤，直到找到出问题的代码这个办法在我一时没有思路或者帮忙他人定位问题的时候十分有用。因为这种做法工夫复杂度大抵是 logn，因而只须要短短几次咱们就能够大抵定位到问题代码。相似地，咱们也能够在多个文件中同时进行二分。 二分提交更多的时候，咱们是在两次公布之间发现了一个 bug。而这两个公布之间是有若干 commit 的，并且 commit 还不少（几十个甚至上百个）。 咱们也能够应用相似的办法。 先切换到两次公布之间的两头提交 x（即便得提交 x 绝对于两次公布之间的间隔差最小）。实际上这个最小间隔差要么是 0， 要么是 1验证问题是否存在。如果不存在，咱们不能确定就是这个提交的问题，无妨先标记以后提交 c 为 good。如果存在，无妨标记以后提交 c 为 bad。 通过下面的标记，咱们就能够找到最早出现 bad 的那次提交，并且最要害的是复杂度为 logn，其中 n 为咱们须要验证的提交的总次数。显然，这个工作量比一一查看 commit 要快很多。不了解其中原理？稍后咱们会讲。Git 中的二分查找git 的开发者也想到了这一点，因而提供了 bisect 命令来帮忙咱们做下面这个事件。 应用 bisect 进行问题查找次要依赖于上面的三个命令： git bisect start启动一个查找，start 前面能够加上 good 和 bad 的提交点： git bisect start [rev bad] [rev good] 如果不加 good 和 bad 的提交点，那么 git 将会等到咱们应用 good 和 bad 命令指定对应的提交点后开始进行查找 ...