关于前端:利用好-git-bisect-这把利器帮助你快速定位疑难-bug

应用 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 d577ce4
or
git bisect start HEAD d577ce4

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

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

kagol:vue-devui kagol$ git bisect start 5d14c34b d577ce4
Bisecting: 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 good
Bisecting: 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 bad
Bisecting: 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 good
c0c4cc1a25c5c6967b85100ee8ac636d90eff4b0 is the first bad commit
commit c0c4cc1a25c5c6967b85100ee8ac636d90eff4b0
Author: 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。