更新された回答:以下のスクリプトの元のバージョンには、$conflicting_files
実際に競合が発生したファイルだけでなく、両方の親ブランチで変更された(必ずしも競合が発生したとは限らない)すべてのファイルが含まれているという意味で欠陥がありました。また、理論的根拠で宣伝されているように「構成されたマージツール」を使用していませんでしたが、diffuse
。スクリプトの現在のバージョンで両方の問題に対処しました。
元の回答:
メインの開発が進行中の「マスター」ブランチと、マスターの(古い)状態にいくつかの機能を追加する「トピック」ブランチがあるとします。マージコミットで変更されたファイルだけを探していると言うことで、マージコミットで「マスター」に導入された「トピック」の変更(競合の解決を含む)にのみ関心があり、非「トピック」が分岐してから「マスター」で行われた競合する変更。さらに、「master」がマージコミットの最初の親であり、「topic」が2番目であると仮定すると、これは次のようにして実現できます。
git difftool <merge commit>^1 <merge commit>
競合解決を含む状態を調べているため、ここで3方向の差分を使用することは意味がないことに注意してください。これは、GitHubがマージコミットに対して表示しているものでもあります。ちなみに、たとえば、テストに使用したこのマージコミットを参照してください。
競合するファイルとその解像度のみを3ウェイ差分ツールで確認するために、このスクリプトを思いつきました。
#!/bin/sh
if [ $# -ne 1 ]; then
echo "Rationale : Show the conflict resolution of a given merge commit in the configured merge tool."
echo "Usage : $(basename $0) <merge commit>"
exit -1
fi
# Test e.g. with https://github.com/git/git/commit/8cde60210dd01f23d89d9eb8b6f08fb9ef3a11b8
our=$1^1
their=$1^2
base=$(git merge-base $our $their)
conflicting_files=$(git merge-tree $base $our $their | grep -A 3 "changed in both" | grep "base" | grep -Po "[^\s]+$")
for f in $conflicting_files; do
diffuse -r $our -r $base -r $their $f
done
Beyond Compareの代わりにDiffuseを使用しています。これは、最初のファイルがローカルファイルではなくGitコミットで直接機能するためです。引数の順序を好みに合わせて変更します。BCを使用するには、おそらく一時的なチェックアウトを行う必要があります。また、マージをやり直し、既知の解決策を適用し、構成されているものを実行することも考えていましたが、これらのアイデアはどちらも、作業ツリーを乱雑にせず、適切にクリーンアップするために、より多くの作業が必要になります。git mergetool