點擊上方?前端Q，關注公眾號

回復加群，加入前端Q技術交流群

使用git bisect二分法定位問題的基本步驟：

git bisect start [最近的出錯的commitid] [較遠的正確的commitid]

測試相應的功能

git bisect good 標記正確

直到出現問題則 標記錯誤 git bisect bad

提示的commitid就是導致問題的那次提交

問題描述

我們以Vue DevUI^[1]組件庫的一個bug舉例子🌰

5d14c34b這一次commit，執行yarn build報錯，報錯信息如下：

??building?client?+?server?bundles... ??rendering?pages... build?error:ReferenceError:?document?is?not?defined 復制代碼

我可以確定的是上一次發版本（d577ce4^[2]）是可以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^[3]之前出現過的一個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?+0800feat(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 復制代碼

github.com/DevCloudFE/…^[4]

整個定位過程幾乎是機械的操作，不需要了解項目源碼，不需要了解最近誰提交了什么內容，只需要無腦地：驗證、標記、驗證、標記，最后git會告訴我們那一次提交出錯。

這么香的工具，趕緊來試試吧！

問題分析

直到哪個commit出問題了，定位起來范圍就小了很多。

如果平時提交代碼又能很好地遵循小顆粒提交的話，bug呼之欲出。

這里必須表揚下我們DevUI的田主（Contributor）們，他們都養成了小顆粒提交的習慣，這次導致bug的提交c0c4cc1a，只提交了4個文件，涉及70多行代碼。

image.png

我們在其中搜索下document關鍵字，發現了兩處，都在drawer-service.ts整個文件中：

一處是12行的：

static?$body:?HTMLElement?|?null?=?document.body 復制代碼

另一處是17行的：

this.$div?=?document.createElement('div') 復制代碼 image.png

最終發現罪魁禍首就是12行的代碼！

破案！

此處@lnzhangsong我們的田主，有空麻煩修下這個bug。

image.png

關于本文

來源：DevUI團隊

https://juejin.cn/post/7046409685561245733

往期推薦

大廠面試官：我理想中的前端

對話Svelte未來，Rust 編譯器？構建大型應用?

收藏！史上最全 Vue 前端代碼風格指南

最后

• 歡迎加我微信，拉你進技術群，長期交流學習...
  

• 歡迎關注「前端Q」,認真學前端，做個專業的技術人...

點個在看支持我吧

總結

以上是生活随笔為你收集整理的利用好 git bisect 这把利器，帮助你快速定位疑难 Bug的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。