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 來解決問題。