29

feature-xと呼ばれる長命のブランチ (ずっと後にリリースされる) での過去のコミット以降に発生したバグの原因を見つけようとしています。

バグはあるけど。特に master の機能は feature-x で頻繁に使用されていますが、Master 自体ではあまり使用されていないため、これまでのコミットのいずれかで導入された可能性があるスクリプトからは予期しない動作を見つけました。

この動作をテストするには、スクリプトdependent.pl を実行する必要があります。しかし、bisect がコードの途中までジャンプすると、私のスクリプトはマスターに存在しないため、テストできません。

これは bisect があなたを頭のない状態に引きずり込むためだと思いますが、この場合、私は本当にこの他の履歴/変更セットのコンテキストになりたいと思っており、エーテルに浮かんでいません.

誰かがあなたのやり方が間違っているブザーを鳴らす前に、私たちのチームはこのような状況でブランチをマージすることを好みます。

サンプル リポジトリを作成して、これをデモします。

git init

echo 'sub f { print $_; }' > main.pl
git add .
git commit -a -m "inital commit"

git branch feature-x
git checkout feature-x
echo 'main::f(1)' > dependent.pl
git add .
git commit -a -m "Starting work on feature X"
git tag dev-1.0

git checkout master
echo "sub f { return 1; }" > main.pl
git commit -a -m "sub f { return 1; }"
echo "sub f { return 2; }" > main.pl
git commit -a -m "sub f { return 2; }"
echo "sub f { return 3; }" > main.pl
git commit -a -m "sub f { return 3; }"

git tag release-1.0

git checkout feature-x
git merge master

echo 'print main::f();' > dependent.pl
git commit -a -m "Updating call to f"

これで、次のようなレポが得られます。

o Updating call to f ( Head of branch 'feature-x' )
o Merge branch master onto feature-x
|\
| o sub f { return 3; } (TAG release-1.0) ( Head of branch 'master' )
| o sub f { return 2; }
| o sub f { return 1; }
o | Starting work on feature X ( TAG 'dev-1.0' )
 \|
  o initial commit

git bisect start feature-x dev-1.0したがって、dependent.pl でコードを壊した原因を見つけることができることを期待してコマンドを実行すると、feature-x からの変更履歴なしで commit 'sub f { return 2 }' になります (つまり、 を実行するlsと、私が見るのは main.pl だけで、dependent.pl がありません)。

これは私をテストできない状態にします。現在のコミットが私の作業を壊したかどうかはわかりませんし、マスターでのコミットがそれを壊したとは言えません。したがって、このコミットが良いとも悪いとも言えません。

現在のブランチを壊した原因をテストするにはどうすればよいですか?

4

1 に答える 1

32

ここでの問題は、git bisectがブランチ対応であることです。「従属」は良いもので「テスト」は悪いものであり、その間の変更の 1 つがマージ コミットであると伝えると、問題がどこに持ち込まれたかを把握するためには、 a、b、および c をコミットします。それ以外の場合は、そのマージ コミットの時点で壊れているかどうかだけがわかります。

あなたが期待しているのは、コミット b と他のブランチからの変更の組み合わせをテストすることです。これは、どのコミットにも存在せず、コミットgit bisectのみをテストできるコンテンツです! そのコンテンツをテストするには、一連のテスト マージを実行する必要があります。b をチェックアウトし、依存関係をマージし、テストさせてから、a または c をチェックアウトして依存関係をマージし、再度テストさせます。git merge --no-commit dependentコミット b で終了したら、非常に簡単に実行できます。次に、git reset --hard実行前のテストが完了したら実行しgit bisect good/badます。

それ以外の場合、マージされたブランチでコミットをテストせず、マージコミット自体のみをテストすると誤解している場合(a、b、または c のどれがそれを壊したかは気にしません)、単にすべてマージされたブランチで良いです。a、b、および c がそれとは何の関係もないことを知っていればなおさらです。そうすれば、それらが優れていることをテストしなくてもわかります!

しかし、期待できないことの 1 つは、git がコミット a、b、および c を完全に無視することです。それらの変更があなたの「バグ」に関連しているかどうかを知る方法はまったくなく、それらの変更はあなたの良いコミットと悪いコミットの違いの一部です.

于 2010-09-09T02:42:33.943 に答える