我是git的新手，剛剛發現「git bisect」。如果您可以使用新編寫的單元測試（事先不在此處）檢查錯誤，通常會如何使用它？如何使用git bisect：使用單元測試來確定錯誤提交？
假設我們有一個包含單元測試的存儲庫，但是 - 經常這樣 - 它們並不完整。在某些版本中，我們發現某個功能無法正常工作，但我們知道它在某些版本之前。不幸的是，該功能沒有通過單元測試進行檢查。我想現在要做的是：
此用例有一個問題。由於git bisect檢查舊版本，剛剛插入的測試用例不在那裏，所以我不能用它來檢查錯誤。我可以嘗試不進行測試，但要保持它作爲本地變化。但是想象一下，在某些版本中，測試文件發生了變化，我很可能會遇到合併衝突。
那該怎麼辦？通常如何使用git bisect？
我通常使用bisect來識別何時引入了一個錯誤，以便我可以查看單個提交錯誤的原因。當我知道某些用於工作的東西時，這非常有用，現在卻不行。我首先選擇或找到一箇舊的提交工作，用git bisect good標記它，用git bisect bad標記頭部，然後通過對分，直到git告訴我引入問題的提交。有時我可以在開始這個過程之前編寫單元測試，有時直到我看到引入該錯誤的代碼才能寫出它。
因此，假設我有單元測試或其他一些代碼或腳本，我需要在通過git bisect過程時使用每個點。當我走時，藏匿處很有用。所以，
git stash save blah
git bisect bad (and now I'm on a new commit)
git stash pop
mvn clean test
git stash save blah
git bisect good
git stash pop
mvn clean test
等等。
首先，在嘗試此操作之前，請確保您的git status是乾淨的 - 我建議使用將調用git reset --hard的腳本，以免任何未提交的更改丟失。
這樣做的一種方法是首先將最近測試的源代碼複製到某個位置，該位置在存儲庫的歷史記錄（或存儲庫外的某個位置）中從未被跟蹤過。然後寫一個腳本：
git reset --hard全殲從步驟1然後保存更改，標誌着兩次提交的好和壞後，得到git bisect的地方，從開始，您可以使用git bisect run YOUR-SCRIPT來查找最近的單元測試失敗的第一次提交。
這種方法本質上是什麼建議in the documentation for git bisect run，在那裏說：
您可能經常會發現平分會話期間，您想擁有臨時修改（如S /＃定義DEBUG 0 /＃定義DEBUG 1 /在頭文件中，或者「沒有這個提交的修訂版本需要這個補丁應用於解決另一個問題，這個分解不是 感興趣的」）適用於被測試的版本。
爲了應對這種情況，在內部git bisect找到下一個修訂版進行測試之後，腳本可以在編譯之前應用修補程序，運行真實測試，然後確定修訂版（可能是否具有所需的修補程序）通過了測試，然後將樹倒回到原始狀態。最後，腳本應該以真實測試的狀態退出，讓「git bisect run」命令循環確定對分會話的最終結果。
您還沒有提及您使用的是哪種技術，因此我將使用Ruby作爲示例，這是我最熟悉的。不過，同樣的原則也適用於其他技術。
將您最新的測試文件外項目目錄的。在這裏，我會以爲這是在/tmp/my_test.rb
裏面你的資料庫中，創建一個小的shell腳本，說，test_runner.sh：
#!/usr/bin/env sh
cp -f /tmp/my_test.rb test/my_test.rb # This will potentially overwrite some old test file
ruby test/my_test.rb # Change for whatever test runner you use
test_result=$?
git checkout test/my_test.rb # Undoes any changes that might have been made
exit $test_result
馬克承諾爲好/壞，由於通常是與bisect完成。
使用git bisect run test_runner.sh去git杯咖啡，而git找到你的bug。