git bisect run 自動二等分
./testテストがOKである場合に終了ステータス0の自動化スクリプトがある場合、次のコマンドでバグを自動的に見つけることができますbisect run。
git checkout KNOWN_BAD_COMMIT
git bisect start
# Confirm that our test script is correct, and fails on the bad commit.
./test
# Should output != 0.
echo $?
# Tell Git that the current commit is bad.
git bisect bad
# Same for a known good commit in the past.
git checkout KNOWN_GOOD_COMMIT
./test
# Should output 0.
echo $?
# After this, git automatically checks out to the commit
# in the middle of KNOWN_BAD_COMMIT and KNOWN_GOOD_COMMIT.
git bisect good
# Bisect automatically all the way to the first bad or last good rev.
git bisect run ./test
# End the bisect operation and checkout to master again.
git bisect reset
もちろんこれは、テストスクリプト./testがGit追跡されている場合、二分割中の以前のコミットで消えないことを前提としています。
私は、ツリー内のスクリプトをツリーから単にコピーし、場合によっては-のPATHような変数で遊んで、代わりにそこから実行することで回避できることが非常に多いことを発見しました。
もちろん、test依存するテストインフラストラクチャが古いコミットに依存しない場合、解決策はなく、コミットを1つずつテストする方法を決定して、手動で行う必要があります。
しかし、この自動化を使用すると多くの場合機能し、タスクのバックログにある遅いテストの時間を大幅に節約できることがわかりました。夜間だけテストを実行し、翌朝までにバグを特定できるので、価値があります。試してみてください。
その他のヒント
に戻る代わりに、bisectの後で最初に失敗したコミットを続行しmasterます。
git bisect reset HEAD
start+最初badにgood、一度に：
git bisect start KNOWN_BAD_COMMIT KNOWN_GOOD_COMMIT~
と同じです：
git checkout KNOWN_BAD_COMMIT
git bisect start
git bisect bad
git bisect good KNOWN_GOOD_COMMIT
これまでにテストされたものを確認します（手動goodおよびbadまたはによってrun）。
git bisect log
出力例：
git bisect log
git bisect start
# bad: [00b9fcdbe7e7d2579f212b51342f4d605e53253d] 9
git bisect bad 00b9fcdbe7e7d2579f212b51342f4d605e53253d
# good: [db7ec3d602db2d994fe981c0da55b7b85ca62566] 0
git bisect good db7ec3d602db2d994fe981c0da55b7b85ca62566
# good: [2461cd8ce8d3d1367ddb036c8f715c7b896397a5] 4
git bisect good 2461cd8ce8d3d1367ddb036c8f715c7b896397a5
# good: [8fbab5a3b44fd469a2da3830dac5c4c1358a87a0] 6
git bisect good 8fbab5a3b44fd469a2da3830dac5c4c1358a87a0
# bad: [dd2c05e71c246f9bcbd2fbe81deabf826c54be23] 8
git bisect bad dd2c05e71c246f9bcbd2fbe81deabf826c54be23
# bad: [c536b1b7242d5fcf92cd87e9a534bedb1c0c9c05] 7
git bisect bad c536b1b7242d5fcf92cd87e9a534bedb1c0c9c05
# first bad commit: [c536b1b7242d5fcf92cd87e9a534bedb1c0c9c0
時間のより良い概念を得るためにgitログに良い参照と悪い参照を表示します：
git log --decorate --pretty=fuller --simplify-by-decoration master
これは、対応する参照を持つコミットのみを示し、ノイズを大幅に削減しますが、タイプの自動生成された参照が含まれます。
refs/bisect/good*
refs/bisect/bad*
これにより、どのコミットが良いか悪いかがわかります。
コマンドをいじりたい場合は、このテストリポジトリを検討してください。
失敗は速く、成功は遅い
時々：
- 失敗が速く発生する、例えば最初のテストの1つが壊れる
- 成功にはしばらく時間がかかります。たとえば、壊れたテストに合格し、他のすべての不要なテストがフォローされます。
これらのケースでは、たとえば、失敗が常に5秒以内に発生すると想定し、テストを実際よりも具体的にするのが面倒な場合は、次のように使用できますtimeout。
#!/usr/bin/env bash
timeout 5 test-command
if [ $? -eq 1 ]; then
exit 1
fi
これは、timeout終了124時にエラーが発生するので終了しtest-commandます1。
魔法の終了ステータス
git bisect run 終了ステータスについて少しうるさいです：
127を超えると、2等分が失敗します。
git bisect run failed:
exit code 134 from '../test -aa' is < 0 or >= 128
特に、C assert(0)はaにつながりSIGABRT、ステータス134で終了し、非常に迷惑です。
125は魔法であり、実行はでスキップされgit bisect skipます。
これの目的は、無関係な理由により壊れたビルドをスキップするのを助けることです。
詳細man git-bisectはをご覧ください。
だからあなたは次のようなものを使いたいかもしれません：
#!/usr/bin/env bash
set -eu
./build
status=0
./actual-test-command || status=$?
if [ "$status" -eq 125 ] || [ "$status" -gt 127 ]; then
status=1
fi
exit "$status"
git 2.16.1でテスト済み。