git bisect

如何在使用Git跟踪長期的變更歷史時排除幾乎所有涉及到的問題，並發現你在代碼中引入的錯誤。 有時我們會長時間地在項目上工作。我們可能會精心製作出一個完美的1.0版本，然後將其發布給公眾，然後我們開始進行錯誤修復，之後我們會收到功能要求並努力改進應用程序。 在此過程中，您發現了一個回歸錯誤：這是由代碼中的非相關更改引起的意外問題。 某些內容沒有按照預期工作，即使您最近並沒有真的更改過該部分的代碼。 或者您經常接觸某個文件或函數，以至於您無法記住哪個更改可能引起了向您報告的問題。 在任何情況下，首先要做的是確定錯誤所在。 如果您使用的是像Git這樣的版本控制系統，事情就變得容易了。您可以回到過去，找出引入該更改的確切提交。在團隊合作時，這非常重要，因為有其他人可能已經處理過這個問題，如果他們導致了錯誤，您可能不知道該怎麼辦 - 除了請他們去修復它，因為Git可以提供這些信息。 一種方法是手動檢出某個特定的提交。例如，您可以檢查昨天的代碼版本是否正常工作。 我使用 GitHub Desktop，這是由GitHub開發的一個很棒的Git客戶端。它非常適合日常使用，但無法讓我檢出單個提交。其他一些客戶端可以，但您可以使用命令行。 運行以下命令： git checkout <COMMIT_SHA> 其中，<COMMIT_SHA>是您想要回溯的提交，它看起來會像 5a06d3ca5e7adb6e67。 如果您仍然遇到問題，您可以尝试使用前一天的另一個提交進行同樣的操作，依此類推，直到找到一個代碼運行正常的提交。 現在，您需要應用“分而治之”的原則，在您嘗試且未發現問題的最後一次提交和運行正常的提交之間選擇一個提交。 重複這個過程，每次將提交的範圍縮小一半，直到找到引入問題的提交。 這是一個常見且實用的方法，Git引入了bisect命令來自動化這個過程。 從最新的提交開始。使用git checkout 您的分支名，例如 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到我提到的“good”提交之間有6個提交。Git告訴我還有2個步驟，直到找到問題所在的提交。 接下來，我測試代碼，然後告訴Git結果：git bisect bad（如果失敗）或 git bisect good（如果成功）。 重複此步驟，直到找到問題所在的壞提交，然後運行 git bisect reset 返回到HEAD提交。...