3

私にとっては、手動で解決された競合は、バグの最大の原因の 1 つです。

現在、私たちは石器時代の慣習であると私が考えている、1 つのモニターの前に大声で集まって紛争を解決しています。さらに、ビジュアル差分ツールを保存して閉じた後、何かを再確認したり修正したりする場合に、後で競合ビューに戻ることができません。

git で手動で解決された最新の競合をすべてすばやく確認する方法を探しています。

すべての競合について、A ブランチ、B ブランチ、およびその結果のコードを確認したいと思います。

必要なツールに手動でコミット番号を与えるか、リストで競合を確認できます。

オフトピック：

私の素晴らしいアイデアは、競合が発生した場合にマージレビューを導入することです。コードのその部分を担当するすべての開発者 (両方の分岐で) は、特にリモートで作業している場合は、競合を確認する必要があります。双方からの確認後にのみマージを許可するのはどうですか?

4

3 に答える 3

2

それはgitでかなり簡単です：

git log --patch -c -1 YOURMERGE

次のように出力されます。

index ea575f9,b943345..239a586
--- a/file-with-conflicts.txt
+++ b/file-with-conflicts.txt
@@@ -1,1 -1,1 +1,1 @@@
- Version A
 -Version B
++Merge Resolution
于 2013-01-24T23:21:38.233 に答える
2

ワークフローを変えることで、これらの「怒鳴り合い」を回避できるのではないかと思います。開発者がトピック ブランチに取り組んでいて、遅れをとっているとしmasterます。

A--B--C--D--E--F
       \
        X--Y--Z

彼またはグループがマージ コミットを思いつく代わりに、彼は自分の変更を自分のローカルにリベースできます。master

 A--B--C--D--E--F
                 \
                  X'--Y'--Z'

その後、適切なタイミングで「公式」マスターへのクリーン マージ コミットが可能になります。

A--B--C--D--E--F--X'--Y'--Z'

参照

于 2013-01-24T16:19:26.067 に答える
0

ページからgit help log：

git log --patch -c -1 <commit-id>

-c このオプションを使用すると、マージ コミットの diff 出力は、一度に 1 つずつ親と結果の間のペアごとの diff を表示するのではなく、各親からマージ結果への違いを同時に表示します。さらに、すべての親から変更されたファイルのみをリストします。

-p, -u, --patch パッチを生成します (パッチの生成に関するセクションを参照してください)。

于 2015-09-01T15:52:59.523 に答える