【问题标题】：Git merge resolve conflicts on symlinksGit 合并解决符号链接上的冲突
【发布时间】：2018-07-10 09:16:38
【问题描述】：

当我将策略设置为-Xours 的分支1 合并到分支2 时，软链接策略不会处理冲突。软链接的合并失败。任何线索如何处理这种情况？

步骤

git checkout branch2
git merge -Xours branch1 -m "syncing branch1"

【问题讨论】：

标签： git merge branch symlink conflict

【解决方案1】：

所有符号链接内容更改都被视为“高级”冲突，而不涉及“低级”合并代码。

作为RomainVALERI answered，-X ours（或--strategy-option=ours）被传递给合并策略，在您的情况下是默认的-s recursive。但对于递归和解析合并，（扩展）策略选项“我们的”仅适用于（普通）文件内的冲突。

请记住 git merge 的工作人员：

找到作为您当前HEAD 提交的共同基点的提交，以及您命名的另一个提交；
实际上做了两个git diff --find-renames：一个从合并基础到HEAD，一个从合并基础到另一个提交；
然后结合这两组更改，或者至少尝试这样做。

（将合并的更改应用到合并基础会产生合并结果。）

两个git diffs 可以找到更高级别（树级）的更改。例如，也许从 merge-base 到 HEAD，您修改了 Readme.txt，但它们删除 Readme.txt。 Git 无法组合这些，-X ours 不赞成您的更改而不是他们的更改：Git 只是声明了一个合并冲突。同样，将文件从“常规文件”更改为“符号链接”不是由-X ours 处理的。

在您的特定示例中，“文件”（实际上是 blob 内容）没有改变模式，它只改变了内容：它曾经是指向某个路径 A 的符号链接，现在它指向您这边的其他路径B，以及他们那边的第三条路径C。 Git 可以通过使用你的 -X ours 来解决这个问题——但它就是没有。 Git 强制您手动解决此冲突，就像它强制您手动解决修改/删除的冲突一样。没有-X 选项会有所帮助。

编辑：这被宣布为一个错误，并在 Git 2.17 中修复。从 Git 2.17 开始，-X ours 或 -X theirs 选择我们或他们的符号链接。因此，如果您的 Git 是 2.17 或更高版本，could 已变为 does。

【讨论】：

【解决方案2】：

-Xours 是一个策略选项，而不是一个合并选项。

我的意思是“-Xours”应该修改策略，比如

git merge -s recursive -Xours mybranch

而“我们的”将是策略本身，作为合并命令的一个选项：

git merge -s ours mybranch

但是，请小心，因为这两个过程是不同的。后者只会忽略“mybranch”分支中的任何更改，而不仅仅是在发生冲突时。

【讨论】：

git merge 默认为-s recursive （好吧，除非你给它更多的头来合并，那么它默认为-s octopus 和-X ours 变得无效）但这仍然是正确的原因： -X ours，传递给递归或解析策略，不会影响符号链接合并，因为这些策略不适用于符号链接内容。
@torek 哦，你是对的，我没有注意到递归是的默认策略。也非常感谢您的详细回答。
我需要保留 branch2 中的更改。所以我不能使用 -s ours 选项。