git bisectの使い方：単位テストを使ってエラーのあるコミットを判断しますか？

Question

私はgitを初めて使い、 "git bisect"を発見しました。新しく書かれた単体テスト（事前にはなかった）を使ってエラーをチェックできるときは、どのように一般的に使用されますか？

ユニットテストが含まれているリポジトリがありますが、頻繁に完了していないとします。いくつかのバージョンでは、機能が動作していないことが判明していますが、以前は一部のバージョンで機能していました。残念ながら、この機能は単体テストではチェックされませんでした。私が今やってみたいことは次のとおりです。

1. は修正
2. このテストケースを使用して二分gitのを使用してエラーを導入するコミットを探し
3. （それはもちろんの最初に失敗した）テストケースを書きますエラーと修正（およびテストケース）のコミット

このユースケースには1つの問題があります。 git bisectは古いバージョンをチェックアウトするので、ちょうど挿入されたテストケースはそこには存在しないので、エラーをチェックするために使用することはできません。私はテストをコミットしないようにすることができますが、ローカルの変更としてそれを維持する。しかし、いくつかのバージョンでテストファイルが変更されたと想像すると、私はマージ競合に遭遇する可能性が高いです。

どうすればよいですか？ git bisectは一般にどのように使用されますか？

Answer 1

私は通常、バグがいつ導入されたかを識別するためにbisectを使用しています。そのため、エラーの原因として単一のコミットを見ることができます。これは、以前は何かがうまく働いていたことを知っていて、今はそうでないときに便利です。私はまず、古いコミットを選択するか、git bisect goodとマークし、頭部にgit bisect badとマークしてから、問題が導入されたコミットをgitに伝えるまでbisectを実行します。このプロセスを開始する前に単体テストを書くこともできますが、バグを導入したコードが見えるまで書き込むことができないことがあります。

だから、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 

などです。

Answer 2

まず、これをしようとする前に、あなたのgit statusがクリーンであることを確認してください - 私はgit reset --hardを起動するスクリプトを使用して示唆していますので、コミットされていない変更は失われます。

これを行う1つの方法は、最新のテストのソースコードを、リポジトリの履歴（またはリポジトリの外のどこか）で追跡されなかった場所にコピーすることです。あなたのソースツリー

で

1. コピーを所定の位置に最も最近のテストでは、リターンコードを保存し、テストを実行します：次に、スクリプトを書きます。
2. 、から開始するgit bisectどこかを与えるために良い点、悪いように2つのコミットをマーキングした後、続いて2

から保存されたリターンコードとステップ1

を終了から変更を一掃するgit reset --hardをいgit bisect run YOUR-SCRIPTを使用して、最新の単体テストが失敗した最初のコミットを見つけることができます。

このメソッドは、それが言うin the documentation for git bisect runを、示唆しているもの、本質的である：

あなたが頻繁に二分セッション中に使用すると、一時的に変更がしたいことがあります（例：S /＃DEBUG 0 /＃を定義DEBUG 1を定義します/ "ヘッダーファイルにあるか、または"このコミットメントを持たないリビジョンは、別の問題を回避するためにこのパッチを適用する必要があります。 に興味があります "）がテスト対象のリビジョンに適用されます。

このような状況に対処するために、内部git bisectがテストする次のリビジョンを見つけたら、スクリプトはコンパイルする前にパッチを適用し、実際のテストを実行した後、（おそらく必要なパッチを使って）テストに合格した後、ツリーを元の状態に戻す。最後にスクリプトは実際のテストの状態で終了して、 "git bisect run"コマンドループがバイセクトセッションの最終結果を決定するようにします。

Answer 3

あなたはどの技術を使用しているかについて言及していないので、ここではRubyを例として使用します。これは私がよく知っているものです。しかし同じ原理が他の技術にも適用されるはずです。

1. プロジェクトディレクトリの外の日付のテストファイルにあなたの最高を置きます。ここで私は、それがあなたのリポジトリ内部/tmp/my_test.rb

2. 上だと仮定言う、小さなシェルスクリプトを作成し、test_runner.shます：通常bisectで行われているよう

   #!/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 
   

3. マークは、悪い/として良いコミットします。

4. git bisect run test_runner.shを使用して、gitがあなたのバグを見つけている間にコーヒーを飲みに行きます。