你是不是有過這樣的經歷：發現代碼中有 錯誤bug，但不知道這個錯誤是什么時候引入的。這有可能是因為，某個人提交了一份有錯誤的代碼，但沒有在他的 Git 提交commit 消息中聲明它。這個錯誤可能已經存在了幾周、幾個月甚至幾年，這意味著你需要搜索數百或數千個提交，才能找到問題何時出現的。而 ??git bisect?? 命令能夠完美地解決這個問題！

??git bisect?? 命令是一個強大的工具。你可以給 ??git bisect?? 命令一個范圍，一端是一個已知的好狀態，另一端是一個已知的壞狀態。它會自動地確認當前范圍的中點，在這個中點上進行測試，然后要求你確定那次提交是一個 好提交good commit 還是一個 壞提交bad commit，然后它會重復這一“二分查找”的過程，直到你找到首次引入錯誤的那一次提交。

Image of Zeno's paradox of Achilles.

這個“數學”工具是利用“二分查找”來找到錯誤之處的。??git bisect?? 命令通過查看中點，然后由你來決定它是提交列表的新起點（即 “壞提交” ）還是新終點（即 “好提交”），進而來縮小查找范圍，如此在幾次查找中你可以就能定位到有錯誤的提交。即使你有 10,000 個提交要檢查，最多只需要 13 次查找，就能很快地定位到首次引入錯誤的提交。

1. 提交 1 壞 <> 提交 10,000 好 => 提交 5,000 是壞的
2. 提交 5,000 壞 <> 提交 10,000 好 => 提交 7,500 是好的
3. 提交 5,000 壞 <> 提交 7,500 好 => 提交 6,250 是好的
4. 提交 5,000 壞 <> 提交 6,250 好 => 提交 5,625 是壞的
5. 提交 5,625 壞 <> 提交 6,250 好 => 提交 5,938 是壞的
6. 提交 5,938 壞 <> 提交 6,250 好 => 提交 6,094 是好的
7. 提交 5,938 壞 <> 提交 6,094 好 => 提交 6,016 是壞的
8. 提交 6,016 壞 <> 提交 6,094 好 => 提交 6,055 是好的
9. 提交 6,016 壞 <> 提交 6,055 好 => 提交 6,036 是壞的
10. 提交 6,036 壞 <> 提交 6,055 好 => 提交 6,046 是壞的
11. 提交 6,046 壞 <> 提交 6,055 好 => 提交 6,050 是壞的
12. 提交 6,050 壞 <> 提交 6,055 好 => 提交 6,053 是好的
13. 提交 6,053 壞 <> 提交 6,055 好 => 提交 6,054 是好的

對于上面這個例子，我們能知道 10,000 個提交中的第一個錯誤提交是第 6053 次提交。對于 ??git bisect?? 命令，最多需要幾分鐘就能完成檢索。但是如果要一個一個查找每個提交是否錯誤，我甚至無法想象需要多長時間。

使用 Git bisect 命令

??git bisect?? 命令使用起來非常簡單：

（LCTT 譯注：使用 ??git bisect start?? 命令來進入 bisect 模式，并且該命令指定了一個檢查范圍。它會告訴我們一共有多少次提交，大概需要幾步就可以定位到具體的提交。）

$ git bisect start$ git bisect bad        # Git assumes you mean HEAD by default$ git bisect good <ref> # specify a tag or commit ID for <ref>

Git 檢查中間的提交，并等待你聲明這次提交是一個好提交還是一個壞提交：

（LCTT 譯注：如果某一提交是可以通過的，則使用 ??git bisect good?? 命令標記；同樣地，如果某一提交不能通過，則使用 ??git bisect bad?? 命令標記。）

$ git bisect good

或

$ git bisect bad

然后，??git bisect?? 工具重復檢查好提交和壞提交中間的那次提交，直到你告訴它：

$ git bisect reset

一些高級用戶甚至可以自己編寫腳本，來確定提交的好壞狀態、并在找到特定提交時采取某一補救措施。你可能不會每天都使用 ??git bisect?? 命令，但當你需要它來定位首次引入錯誤的提交時，它會是一個很有用的救星。