1

私がgitでこの状況にあるとしましょう:

  B---D---F---H---J---K--->topic
 /       /       /
A---C---E---G---I--->master

コミット F まで到達したら、レビューのためにトピック ブランチを送信します。レビュアーがいくつかの提案を行い、世界が動き出すので、別のマージが行われます。ここで答えたように、トピックブランチの Git diff、その間に発生したマージコミットを除外しますか? A から F への差分を単純に生成する方法git diff master..topic。ただし、リビジョン B と D は既にレビュー済みであり、レビューのために新しい diff から除外したいと考えています。git diff E..topicただし、G と I が含まれます。

G と I から引き込まれたものを除いて、H、J、K の差分を取得するにはどうすればよいですか?

4

2 に答える 2

1

マージ diff を含むいくつかの特別なケース ( を使用できる場合) を除いて--combined、コミット diff は常にペアワイズです。これにより、x..y解釈される方法が変わります。yこの意味は、「から到達可能で、そこから到達できないすべてのリビジョン」という意味ではなく、「リビジョンとリビジョンをx比較する」という意味です。xy

(ここで、リンクされた質問の回答は、他の git コマンドx..yとは異なる方法で解釈されるという事実を覆い隠していることに注意してください。)git diff

を要求するとE..topic、git はtopic特定のコミット (この場合) に解決し、Kのツリーと のツリーを比較しEますK。Gとからの変更が表示されるのはそのためです。これらの変更はマージIによってもたらされたからです。J

Fとを比較することもできますが、これらの変更は実際には にあるため、KこれでもGとの変更が表示されます。IJ

実際、そのようにそのままJ維持しながら何が起こったのかを無視する唯一の方法があります。それは、それをスキップするか、元に戻すツリーを構築することです。たとえば、 から開始して、との間の差分に基づいてパッチを追加できます。FHHJK

                K'        <-- HEAD[detached]
               /
  B---D---F---H---J---K   <-- topic
 /       /       /
A---C---E---G---I         <-- master

(これを行うにはgit checkout topic~2、 commitHでdetach してから、現在の detached に からへの変更git cherry-pick topicを追加します)。HEADJK

Eこれで、コミット中のツリーとHEAD(コミット時K')のツリーを比較できます。

git diff E HEAD   # or   git diff E..HEAD   or   git diff E..

しかし、それは一般的に、人々がレビューしたいものではありません. 実際、後で rev をK'完全に放棄する (レビュー目的でのみ生成する) ことはほぼ確実であるため、彼らは一度も使用されていないバージョンのコードをレビューすることになります!

これが、リンクされた質問に対する受け入れられた答えが単に— とまったく同じである理由です。この場合、 のツリーとのツリーを比較します。のようなツリーをブランチ に送信することを提案しています。それが に入るコードです。の revにあるコードとは多少の違いがあります。それがしなければならない違いは、 、、 、および適合させるために行われたシム作業の合計です。 で行われた変更(およびもちろんそれ自体) がありますが、それらはへの変更ではありません。git diff master..topicgit diff master topicIKtopicKtopicImasterIFHKJGI I、それらは単に に組み込まれ Iた変更です。

コードをレビューするより徹底的な方法は、レビュー用に 4 つの差分を提示することです。

  1. E対F
  2. F対H
  3. Hvs J(おそらく複合 diff、H-and- Ivs J)
  4. J対K

最初の diff は、レビュアーに、彼らがそれを受け入れれば、次のようなツリーをチェックアウトできるようになることを伝えていますF(これは確かに真実です。ただgit checkout F)。2 番目の diff は、レビュアーに、レポがあれば、(彼らがそれを受け入れれば)Fチェックアウトできるようになることなどを伝えます。明らかに、4 つのレビューは 1つよりも難しいです。HIK

于 2013-10-28T15:19:57.123 に答える
0

Ftorek の提案 (複数のレビューを行う) は可能ですが、改善が必要であると言われて修正されたコードはH、2 回レビューする必要があるという不幸な副作用があります。終了しました。良い点git diff master..topicは、これらを押しつぶして、ブランチ間の最終的な違いを与えるだけだったことです。

問題を解決するために私がしたことは、 からブランチを作成し、そこFにマージmasterしてから、新しい一時ブランチとブランチの間で diff を実行することtopicでした。そうすれば、へのすべての変更masterが見過ごされ、topic前回のレビュー ポイント以降のブランチへの変更のみが使用されます。

于 2013-10-29T16:37:48.470 に答える