更新的答案:我下面脚本的原始版本是有缺陷的,$conflicting_files
事实上它不仅包含真正有冲突的文件,还包含在两个父分支中更改的所有文件(但不一定有冲突)。此外,它没有使用基本原理中宣传的“配置的合并工具”,而是diffuse
. 我已经在当前版本的脚本中解决了这两个问题。
原始答案:
假设我们有一个“master”分支,主要开发正在进行中,还有一个“topic”分支,它在 master 的某些(旧)状态之上添加了一些功能。通过说您只是在寻找合并提交中更改的文件,我假设您只对合并提交中引入“主”的更改“主题”感兴趣(包括任何冲突解决),而不是非自“主题”分支以来在“主”中完成的冲突更改。进一步假设“master”是合并提交的第一个父级,“topic”是第二个父级,这可以通过
git difftool <merge commit>^1 <merge commit>
请注意,在这里使用 3-way diff 是没有意义的,因为我们正在查看包含任何冲突解决的状态。这也是 GitHub 为合并提交显示的内容,顺便说一下,请参阅我用于测试的这个合并提交。
为了在 3-way diff 工具中只查看冲突文件及其分辨率,我想出了这个脚本
#!/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
我使用的是Diffuse而不是Beyond Compare,因为第一个可以直接处理 Git 提交而不是本地文件;根据您的喜好更改参数的顺序。要使用 BC,您可能需要进行临时结帐;我也在考虑重做合并,应用已知的分辨率,并运行任何git mergetool
配置过的东西,但是这两个想法都需要更多的工作才能不弄乱你的工作树并正确地进行清理。