Git + GitHub 版本控制教學 (8) - 使用 Bisect 快速定位 Bugs

在開發軟件的過程中,我們可能會遇到一些難以追踪的 Bugs,尤其是那些在之前版本中不存在,卻在當前版本中突然出現的問題。定位這些 Bugs 可能非常耗時,特別是在代碼庫隨著時間的推移變得越來越龐大時。這時候,如果能有一個工具可以幫助我們快速找到引入 Bug 的那次提交,那將會大大加快修復進程。Git 的 Bisect 功能就是為此而生。

Git 的 Bisect 功能提供了一種二分搜索的方法,幫助我們快速找到導致問題的那個特定提交。讓我們一步一步來看看如何使用這個功能。

使用 Git Bisect 的基本流程

第一步,當我們確認當前的版本中存在 Bug,而之前的某個版本是好的,我們可以開始一次 Bisect 會話。

git bisect start

上述命令初始化了 Bisect 會話,Git 會進入一個特殊模式,用於二分搜索。

接下來,我們需要告訴 Git 好的版本和壞的版本。找到一個沒問題的版本就標記 git bisect good ,再找某個有問題的版本標記 git bisect bad

git bisect bad # 標記當前版本為壞的
git bisect good v1.2.3 # 假設 v1.2.3 是最後一個好的版本

告訴 Git 這兩個重要的點後,Git 會自動將我們的代碼庫切換到中間的提交。我們的任務就是檢查這次提交是否好或壞。我們可以通過運行我們的測試或手動檢查來決定。

如果當前的提交是好的,我們就繼續執行 git bisect good

如果是壞的,我們執行 git bisect bad

每次回應後,Git 都會基於我們的回答進行下一輪二分搜索,再次將我們帶到另一個提交,直到找到那個導致問題的壞提交。

找到壞提交後,會看到類似以下的輸出:

7b9f22b4d7f3b9f577eb8d998b8dd4ec3aeb3afb is the first bad commit

確認後,我們可以使用以下命令來結束 Bisect 會話,並返回到我們的原工作分支:

git bisect reset

這樣,Git 就幫助我們節省了手動檢查每個提交的時間,快速定位到問題。這個功能在對付那些“潛伏”已久的 Bugs 時尤其有效。

但是要注意,有效使用 Git Bisect 的前提是我們有一套好的測試流程,或者對代碼的預期行為有很清晰的認識。此外,在進行 Bisect 之前確保工作目錄是乾淨的,也是一個好習慣,以免影響結果。

我在公司遇到的一次狀況,我們的網站在一次 release 之後性能急劇下降,翻遍了那次的 code changes 也找不到任何端倪。於是,我決定運用 Git 的 Bisect 功能,來定位問題的根源。

過程中,我們運行性能測試,查看效能是否受到影響,最終在一系列的提交中發現了那個看似無害的變更 – 在 Material-UI 的 Drawer component 上添加了一個 box-shadow: none 的樣式。令人難以置信,一行簡單的樣式規則竟然拖慢了整個網站的速度。

“在一堆乾草堆裡找針,何不點燃它們,用磁鐵吸引剩下的針呢?” Git Bisect 就像是那磁鐵,而每次二分搜索則是逐步焚燒乾草堆的過程。

總結來說,Git Bisect 是一個強大的工具,用於幫助開發者節省時間,快速找到造成問題的提交。特別是在與一個龐大且複雜的代碼庫工作時,這個工具的價值不言而喻。在日常開發過程中,如果遇到了令人困惑的 Bugs,不妨試試看用 Git Bisect 來解決問題。