如何使用git bisect發現錯誤

我如何調試幾乎所有涉及長期變更歷史的問題,使用Git進行跟踪,並發現在代碼中引入錯誤的時間

有時我們從事項目的時間很長很長時間。我們可能會製作完美的1.0版本,然後將其發布給公眾,然後開始進行錯誤修復,然後收到功能要求,並致力於改進應用程序。

在此過程中的某個時候,您會得到一個回歸錯誤:由於代碼的不相關更改而引起的意外問題。

儘管您最近並沒有真正更改那部分代碼,但是某些事情並沒有按預期工作。

或者,也許您觸摸了文件或功能太多次,以致忘記了什麼更改可能導致了報告給您的問題。

無論如何,第一件事就是確定錯誤在哪裡

如果您使用的是版本控制系統,例如吉特,事情比較容易。您可以回到過去,找出引入更改的確切提交。在團隊中工作時,這一點很重要,因為其他人可能已經在進行此工作,並且如果他們引起了錯誤,則您可能不知道該怎麼做-除了要求他們進行修復之外,因為Git會為您提供此信息。

一種方法是手動檢出某些特定的提交。例如,您可以從檢查昨天的代碼庫版本是否正常開始。

我用GitHub桌面,真棒的Git客戶的GitHub。它非常適合日常使用,但不允許我檢查一次提交。其他一些客戶也可以,但是您可以使用命令行

git checkout <COMMIT_SHA>

在哪裡是您要回滾的提交。它看起來像5a06d3ca5e7adb6e67

如果問題仍然存在,請嘗試從前一天開始對另一個提交執行相同的操作,依此類推,直到找到代碼可以正常工作的提交為止。

現在,您需要應用分而治之原理,然後在您嘗試的最後一個(無效)和可行的中間選擇一個提交。

重複該過程,每次提交間隔減少一半,直到您確定引起問題的提交。

這是一件普通而有用的事情,因此Git引入了bisect命令以自動執行此過程。

從您的最新提交開始。使用git checkout your-branch-name, 例如git checkout master如果您已經簽出了較早的提交。

然後運行:

git bisect start

什麼都沒發生您需要告訴Git一個壞的提交引用,其中代碼不起作用:

git bisect bad HEAD

和一個好的提交,代碼在哪里工作:

git bisect good 7f4d976e7540e28c6b0

Git啟動該過程:

Bisecting: 3 revisions left to test after this (roughly 2 steps)
[d18ebf1c7db9a9b44e8facc5ddb3551e641a64e2] fixes #25

看,您在HEAD和我提到的很好的提交之間有6次提交。 Git告訴我,還有2個步驟,直到找到有問題的提交為止。

我去測試代碼,然後告訴Git結果:git bisect bad或者git bisect good取決於成功。

重複直到找到錯誤的提交,然後運行git bisect reset回到HEAD提交。

Git將指導您進行二等分的操作。您輸入提交的SHA


更多git教程: