問題タブ [git-bisect]

最近使ってみましたgit bisectが、うまくいきませんでした。ツリーはマスターのままで、git bisect何も出力されませんでした。これが私が試したことです：

これを2つの異なるリポジトリで試しました。うまくいきませんでした。git --version は Ubuntu 9.10 では 1.6.3.3 です

git bisectセッションを開始するときの私の通常のワークフローは次のとおりです。

さて、過去にうまくいったことはよく知っていますが、どのバージョンが良かったかはまだわかりません。そのため、通常、作業ツリーを古い状態に戻し、ビルド、テストを行い、動作するバージョンが見つかるまで繰り返します。でマークできgit bisect goodます。

「作業ツリーを古い状態に戻す」手順を実行するための最良の方法は何ですか？git reset --hard <some_good_rev>？git checkout <some_good_rev>？他に何かありますか？あなたの答えを正当化してください。

git-bisectは、リビジョンでバイナリ検索を実行し、どの変更が設計を壊したかを把握するためのフックを提供します。Perforce 用の同等のスクリプトはありますか? 私は運が悪いのでSOとGoogle検索をしました。

2010 年 3 月 1 日の更新: Douglas Leeder が正しく指摘したように、これは線形の履歴では簡単です。ただし、ブランチ間でマージが行われている複数のブランチがあるため、線形履歴の場合ほど簡単ではありません。さらに、コードのビルドとテストにはある程度の時間 (数時間) がかかるため、自動テストは、私が戻ってくることなく実行でき、夜間/週末に実行できると便利です。

私は git で bisect コマンドを広範囲に使用する傾向があります。今、私はSubversionリポジトリで同じことをしたいと思っています. Subversion リポジトリを二分する最良の方法は何ですか?

svn リポジトリを git に変換することはオプションではありません。これはかなり大きいリポジトリであり、svn サーバーが非常に遅いためです。変換には数日かかります。

コミットを誘発する失敗を見つけるためにgitbisectを使用しています。ただし、範囲内のコミットの多くは、明らかに無関係です（ドキュメントまたは単体テストへのコミットであるため）。特定のディレクトリ内のファイルに影響を与えるコミットをgitbisectが自動的にスキップするようにしたいと思います。これはどういうわけか可能ですか？

場合によっては、git bisectセッション中に特定のコミットをテストするのに非常に時間がかかることがあります (たとえば、完全なリリース パッケージをビルドして、特に見慣れないマシンにデプロイする必要があるため)。実際、ビルドのテストには非常に時間がかかるため、現在のテストが成功するかどうかを知らずに、次の 2 つのコミットのビルドを開始したいと考えています。そうすれば、現在のバージョンをテストし、次の 2 つのバージョンを並行してビルドすることで、バイセクティングを高速化できます。

git bisect現在のコミットが良いか悪いかに応じて、次の 2 つのリビジョンを表示するトリックを知っている人はいますか?

git bisect私はそれが素晴らしいと言っているいくつかの記事を読みました。しかし、私はネイティブ スピーカーではないので、なぜそれが素晴らしいのか理解できません。

誰かがいくつかのコードサンプルで実演してくれませんか:

1. それの使い方？
2. のようsvn blameですか？

私の中には次のものがあります~/.gitconfig （これは私が見ているものを理解するのを助けるためにここにのみあります）：

を実行するgit logと、ブランチ名などを含む完全なコミットツリーが表示されます。昨日私はを開始しました、git bisectそして今日私refs/bisect/badは私のログの出力に枝があるのを見ます。

ブランチとは正確には何ですかrefs/bisect/bad？どうすればそれを取り除くことができますか？

git bisect は設計上ブランチ対応であることを認識しているため、適切なコミット (G) と不適切なコミット (B) の間でブランチにマージした場合、バグが発生する可能性があるため、それらの変更も考慮する必要があります。ブランチに含まれます。

私の場合、サイド ブランチとして依存関係があり、時々メイン プロジェクトに変更をマージします。依存関係は、メイン プロジェクトとは異なる実行方法、異なるビルド システムなどを持つライブラリと見なすことができますが、メイン ブランチへのマージを介して最近の変更が必要です。

問題は、このシナリオで二分している間に、依存関係からのコミットでコンパイル不能なコミットになってしまうことです。

二分法を実行している間、各ブランチのマージを単一のコミットと見なしたいだけです。

私がこれまでに見つけた回避策は、有効なコミット G..B のリストを git log --first-parent で作成し、バイセクト中に、現在のコミットがそのリストにない場合は git bisect skip を実行することです。ただし、これには多くの時間がかかります（スキップするたびにチェックアウト/変更するファイルがたくさんあります）。

質問は次のとおりです。 --first-parent を git bisect で実行する方法や、既にコンパイル可能ではないことがわかっているブランチのチェックアウトを回避できる有効なコミットのリストを提供する方法はありますか? 図でoとマークされているコミットのみを確認するにはどうすればよいですか?

編集：明確にするために図を追加

コマンドラインから自動化されていないgitbisectを実行しています。コマンド履歴の間違った行で誤ってreturnキーを押すまで、すべてが順調に進んでいます。テストを実行するのではなく、「git bisectgood」（またはbad）を実行します。おっと-このコミットを良いか悪いかはまだわかりませんが、それは私がやったことです。

'git bisect good'コマンドを元に戻すか、gitにその結果を忘れさせて、戻ってそのコミットのテストを実行できますか？