在整理之前那篇 [Git 分支管理]1 的时候接触了 git bisect ，用了那么长时间的 git 竟然又出现了一个不曾用过的命令，于是就看了下文档学习下使用。

git bisect 使用二分查找来快速定位出错的 commit，举个例子来说，假设线上正常运行的一个版本，之后进行了大量的开发，提交了成百上千次提交，而导致了线上其中一个小功能的失效。为了定位问题，你可能需要查看过去的提交。

  • 如果你知道这个功能具体在那个文件，那其实很好办，git blame 找出修改的部分，修正即可
  • 而如果提交实在太多，无法定位问题文件的话，那么就需要使用 git bisect

git bisect 使用

在使用之前你需要知道两个前提，一个是已知的正常运行的版本，一个是出问题的版本，git bisect 会在两个版本之间使用二分查找，然后根据定位的 commit id 创建新的分支，然后在此分支上可以进行检查，是否有问题。

假设这个中间版本依然可以运行，那么通过 git bisect good 命令告诉 git，然后进行剩下一半的查找，以此类推，最终会快速的定位到问题所在 commit。因为每次都把提交历史切为两半，所以非常快，时间复杂度 log(n)

运行 git bisect 的整个过程

git bisect start         # 告诉 git 开始二分查找
git bisect good [good-commit-id] # 告诉 git 该版本无问题
git bisect bad [bad-commit-id]   # 告诉 git 出问题版本 git bisect bad HEAD
# 此时 git 就会检出中间版本，然后就可以去测试该版本
git bisect good/bad      # 此时就会遇到两种可能，有问题或者无问题，使用 good/bad 来告诉 git
# 当找到第一个问题版本后，git 会告诉你 bisect 结束
git bisect reset         # 返回到 git bisect 初始的版本
git bisect log           # 显示最后一次完全成功的 git bisect 日志

git branching

看完整个过程就知道了为什么在 [Git 分支管理]1 那篇文章中要提到这个 bisect 了，因为如果在 master 上的提交每次都 rebase ，而不是使用 merge ，就会让 master 分支非常干净，而 bisect 去查找的时候就不会那么的费力，而如果 master 分支非常多的分叉，查找过程就会非常费力了。

  1. Git 分支管理 ↩ ↩2