9

私はgitを初めて使用し、「git bisect」を発見しました。新しく作成された単体テスト (事前に存在しなかったもの) を使用してエラーをチェックできる場合、一般的にどのように使用されますか?

単体テストを含むリポジトリがあるとしますが、よくあることですが、それらは完全ではありませんでした。一部のバージョンで機能が動作していないことを発見しましたが、それが以前のバージョンにあったことはわかっています。残念ながら、その機能は単体テストではチェックされていません。私が今やりたいことは次のとおりです。

  1. テスト ケースを作成します (もちろん、最初は失敗します)。
  2. このテスト ケースを使用して、git bisect を使用してエラーを導入しているコミットを探します。
  3. エラーを修正し、修正 (およびテスト ケース) をコミットする

この使用例には 1 つの問題があります。git bisect が古いバージョンをチェックアウトすると、挿入されたばかりのテスト ケースが存在しないため、エラーのチェックに使用できません。テストをコミットせずに、ローカルの変更として保持することができます。しかし、tests ファイルが途中のバージョンで変更されたと想像すると、マージの競合が発生する可能性があります。

じゃあ何をすればいいの？git bisect は一般的にどのように使用されますか?

4

3 に答える 3

12

私は通常 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

など。

于 2012-10-06T14:10:54.667 に答える
2

まず、これを試す前に、あなたgit statusがクリーンであることを確認してください - を呼び出すスクリプトを使用することをお勧めします。そのgit reset --hardため、コミットされていない変更はすべて失われます。

これを行う 1 つの方法は、最初に最新のテストのソース コードをリポジトリの履歴で追跡されたことのない場所 (またはリポジトリ外の場所) にコピーすることです。次に、次のようなスクリプトを作成します。

  1. 最新のテストをソース ツリーにコピーします
  2. テストを実行し、リターン コードを保存します。
  3. git reset --hardステップ 1 からの変更を一掃するためにaを実行します
  4. 2 から保存された戻りコードで終了します。

次に、2 つのコミットを良いものと悪いものとしてマークし、git bisectどこから開始するかを指定した後git bisect run YOUR-SCRIPT、最新の単体テストが失敗した最初のコミットを見つけるために使用できます。

このメソッドは基本的に、 のドキュメントでgit bisect run提案されているもので、次のように書かれています。

bisect セッション中に、一時的な変更 (例: ヘッダー ファイル内の s/#define DEBUG 0/#define DEBUG 1/ や、「このコミットを持たないリビジョンには、このパッチを適用して回避する必要があります。この二分法が関心を持たない別の問題") がテスト対象のリビジョンに適用されます。

このような状況に対処するために、内部の git bisect がテストする次のリビジョンを見つけた後、スクリプトはコンパイル前にパッチを適用し、実際のテストを実行し、その後リビジョン (おそらく必要なパッチを含む) がテストに合格したかどうかを判断し、次に、ツリーを手付かずの状態に巻き戻します。最後に、スクリプトは実際のテストのステータスで終了し、「git bisect run」コマンド ループが bisect セッションの最終的な結果を決定できるようにする必要があります。

于 2012-10-06T14:12:49.683 に答える
1

使用しているテクノロジーについて言及されていないので、例として、私が最もよく知っている Ruby を使用します。ただし、同じ原則が他のテクノロジーにも適用されるはずです。

  1. プロジェクト ディレクトリの外に最新のテスト ファイルを配置します。ここでは、オンになっていると仮定します/tmp/my_test.rb

  2. リポジトリ内で、次のような小さなシェル スクリプトを作成します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

  3. 通常は で行われるように、コミットを良い/悪いとしてマークしbisectます。

  4. git bisect run test_runner.shgit がバグを見つけている間、コーヒーを飲みに行きましょう。

于 2012-10-06T14:16:05.087 に答える