testscript.sh
#!/bin/bash result=`./project.sh` echo $result if [[ "$result" == "GOOD" ]] then echo "Test passed" exit 0 elif [[ "$result" == "BAD" ]] then echo "Test failed" exit 1 else echo "Can not apply test" exit 125 fi
git bisect start ./testscript.sh git bisect bad ./testscript.sh git bisect good …
同社はリベースを使用し、コミット履歴は線形であり、アントンを検索するのは喜びでした。
突然：
-うーん...プロジェクトはコンパイルされず、テストは機能しません。 関係ありません。スキップしましょう： git bisect skip 。
-なんてナンセンス？ 再びコンパイルされません。 もう一度スキップ...
-再び??? どの
@#$%^
が非常に多くの壊れたコミットをプッシュしましたか？
しばらくして、Antonの前に暗い画像が表示されました。30件のコミットで、プロジェクトは行きません。その中のどこかでエラーが発生したコミットです。
アントンはヴァシャの番号をダイヤルしました。
アントン：-こんにちは、ヴァシリー！ 教えてください。プロジェクトの元になるリポジトリの30個のリビジョンはどこですか？
Vasya：-ああ...覚えてる、覚えてる。 ブランチで重要な機能を開発しました。すべてのテストを実行する前に、30のコミットがあり、それぞれが完全に変更されました。 しかし、この時点で、ウィザードのPetyaは、私のコミットで使用されていたAPIを大幅に変更しました。 したがって、私がローカルでリベースを行ったとき、私のコミットはペティニーの後にあり、プロジェクトはそれらの収集を停止しました。
アントン：そして、何を押す前にチェックしなかったのですか？
Vasya：-もちろんそうです。 そして、彼は私の機能を新しいAPIに移行するコミットを作成しました。その後、プロジェクトが再び組み立てられ始めました。
アントン：-そして、これらの30のコミットでエラーをローカライズする方法を教えてください。
Vasya：-すみません、アントン。 私は解雇され、今ではこれは私の問題ではありません。
並行現実のこの時点で..
アントンは非常に重要なプロジェクトでバグの原因を探し始めました。 会社はマージを使用します。コミット履歴は非線形であり、履歴による手動検索はアントンに喜びを与えないため、事前に準備されたスクリプトを使用してこのgit-bisectビジネスを委任します。
git bisect run ./testscript.sh
Git bisectは、コミットを元気に実行し、テストスクリプトを自動的に実行し、良好/不良ラベルを設定し、唯一の機能しないコミットをスキップして結果を返しました。
f35d44060c4f2ae251046c0c20ae1e1f68044812 is the first bad commit
アントン：-やあ、ヴァシリー！ f35d440にエラーがあります。
Vasya：-なるほど。
5分後：
Vasya：-完了、修正。
アントン：わかりました。
道徳：リベース（ローカルを含む）は、コミットが書き込まれたコンテキストを変更し、「壊れた」リビジョンが履歴に残る可能性があります。 これを覚えて。
githubのサンプルプロジェクト。