应用git bisect二分法定位问题的根本步骤：

  1. git bisect start [最近的出错的commitid] [较远的正确的commitid]
  2. 测试相应的性能
  3. git bisect good 标记正确
  4. 直到呈现问题则 标记谬误 git bisect bad
  5. 提醒的commitid就是导致问题的那次提交

问题形容

咱们以Vue DevUI组件库的一个bug举例子

5d14c34b这一次commit，执行yarn build报错，报错信息如下：

✓ building client + server bundles...✖ rendering pages...build error: ReferenceError: document is not defined

我能够确定的是上一次发版本（d577ce4）是能够build胜利的。

git bisect 简介

git bisect命令应用二分搜索算法来查找提交历史中的哪一次提交引入了谬误。它简直能让你闭着眼睛疾速定位任何源码导致的问题，十分实用。

你只须要通知这个命令一个蕴含该bug的坏commit ID和一个引入该bug之前的好commit ID，这个命令会用二分法在这两个提交之间抉择一个两头的commit ID，切换到那个commit ID的代码，而后询问你这是好的commit ID还是坏的commit ID，你通知它是好还是坏，而后它会一直放大范畴，直到找到那次引入bug的凶手commit ID。

这样咱们就只须要剖析那一次提交的代码，就能疾速定位和解决这个bug（具体定位的工夫取决于该次提交的代码量和你的教训），所以咱们提交代码时肯定要养成小批量提交的习惯，每次只提交一个小的独立性能，这样出问题了，定位起来会十分快。

接下来我就以Vue DevUI之前呈现过的一个bug为例，具体介绍下如何应用git bisect这把利器。

定位过程

git bisect start 5d14c34b d577ce4orgit bisect start HEAD d577ce4

其中5d14c34b这次是最近呈现的有bug的提交，d577ce4这个是上一次发版本没问题的提交。

执行完启动bisect之后，马上就切到两头的一次提交啦，以下是打印后果：

kagol:vue-devui kagol$ git bisect start 5d14c34b d577ce4Bisecting: 11 revisions left to test after this (roughly 4 steps)[1cfafaaa58e03850e0c9ddc4246ae40d18b03d71] fix: read-tip icon款式泄露 (#54)

能够看到曾经切到以下提交：

[1cfafaaa] fix: read-tip icon款式泄露 (#54)

执行命令：

yarn build

构建胜利，所以标记下good：

git bisect good
kagol:vue-devui kagol$ git bisect goodBisecting: 5 revisions left to test after this (roughly 3 steps)[c0c4cc1a25c5c6967b85100ee8ac636d90eff4b0] feat(drawer): add service model (#27)

标记万good，马上又通过二分法，切到了一次新的提交：

[c0c4cc1a] feat(drawer): add service model (#27)

再次执行build命令：

yarn build

build失败了，呈现了咱们最早遇到的报错：

✓ building client + server bundles...✖ rendering pages...build error: ReferenceError: document is not defined

标记下bad，再一次切到两头的提交：

kagol:vue-devui kagol$ git bisect badBisecting: 2 revisions left to test after this (roughly 2 steps)[86634fd8efd2b808811835e7cb7ca80bc2904795] feat: add scss preprocessor in docs && fix:(Toast)  single lifeMode bug in Toast

以此类推，一直地验证、标记、验证、标记...最终会提醒咱们那一次提交导致了这次的bug，提交者、提交工夫、提交message等信息。

kagol:vue-devui kagol$ git bisect goodc0c4cc1a25c5c6967b85100ee8ac636d90eff4b0 is the first bad commitcommit c0c4cc1a25c5c6967b85100ee8ac636d90eff4b0Author: nif <lnzhangsong@163.com>Date:   Sun Dec 26 21:37:05 2021 +0800    feat(drawer): add service model (#27)        * feat(drawer): add service model        * docs(drawer): add service model demo        * fix(drawer): remove 'console.log()' packages/devui-vue/devui/drawer/index.ts           |  7 +++-- .../devui-vue/devui/drawer/src/drawer-service.ts   | 33 ++++++++++++++++++++++ packages/devui-vue/devui/drawer/src/drawer.tsx     |  3 ++ packages/devui-vue/docs/components/drawer/index.md | 29 +++++++++++++++++++ 4 files changed, 69 insertions(+), 3 deletions(-) create mode 100644 packages/devui-vue/devui/drawer/src/drawer-service.ts

最终定位到出问题的commit：

c0c4cc1a is the first bad commit

https://github.com/DevCloudFE/vue-devui/commit/c0c4cc1a25c5c6967b85100ee8ac636d90eff4b0

整个定位过程简直是机械的操作，不须要理解我的项目源码，不须要理解最近谁提交了什么内容，只须要无脑地：验证、标记、验证、标记，最初git会通知咱们那一次提交出错。

这么香的工具，连忙来试试吧！

问题剖析

直到哪个commit出问题了，定位起来范畴就小了很多。

如果平时提交代码又能很好地遵循小颗粒提交的话，bug跃然纸上。

这里必须褒扬下咱们DevUI的田主（Contributor）们，他们都养成了小颗粒提交的习惯，这次导致bug的提交c0c4cc1a，只提交了4个文件，波及70多行代码。

咱们在其中搜寻下document关键字，发现了两处，都在drawer-service.ts整个文件中：

一处是12行的：

static $body: HTMLElement | null = document.body

另一处是17行的：

this.$div = document.createElement('div')

最终发现罪魁祸首就是12行的代码！

破案！

此处@lnzhangsong咱们的田主，有空麻烦修下这个bug。