我们正在使用
git merge --no-ff -Xignore-all-space -Xours masterBranch
以在全自动构建管道中从某个 masterBranch 自动刷新集成分支。这会自动解决现有文件中的合并冲突，方法是从集成分支(目标分支(中获取大块头。
但是，这仍然会导致合并冲突，以防在两个分支(CONFLICT (add/add): Merge conflict in ...(上新添加文件，并且这些冲突不会自动解决并且合并将停止，等待手动解决冲突。
- 在这种情况下，为什么
-Xours不只是从"我们的"分支中获取整个文件，就像处理其他冲突一样？ - 有没有办法配置
git merge以便在发生添加/添加冲突时，它确实从"我们的"分支中获取文件而不是停止合并？
(这是 git 2.15.0(
添加/添加"冲突是一组冲突的一部分，我还没有找到一个真正好的名字，但我们可以称它们为高级冲突或树冲突。 这些还包括重命名/删除和重命名/重命名。
要了解这意味着什么，请记住git merge的工作原理是：
- 查找合并库(在两个分支上共享(提交;
- 将合并基础与每个提示进行比较：可以说是两个
git diff。
两个git diff命令的输出显示某些文件已更改，某些文件已创建、删除或重命名。
这两个差异有不同的标签("我们的"和"他们的"，"本地"和"远程"，等等(，但如果他们附上一个人的名字，大多数人可以更好地概念化它们，所以假设基本与我们的更改是由爱丽丝进行的，而基本与他们的更改是由鲍勃进行的。
假设 Alice 和 Bob 都从一个名为READ.ME的文件开始。 爱丽丝不得不在更改它时README.txt重命名它，而鲍勃只是就地更改了它。 为了合并Alice 和 Bob 的更改，Git 将接受这两项更改，并将文件从READ.ME重命名为README.txt。 这是一个不冲突的重命名：Git 可以从它运行的两个git diff中的每一个中看出 Alice 在更改文件时重命名了文件，而 Bob 在更改文件时保留了文件名。
此文件中的内部更改(其名称已在 Alice 端(但不是 Bob(更改(可能会也可能不会冲突。 如果他们确实发生冲突，-X ours会告诉 Git 更喜欢谁的更改：Alice 的或 Bob 的。 这些类型的冲突是低级冲突：在单个文件中，在扫描更高级别"树"更改(已创建、重命名或删除的文件(后确定。
不幸的是，Git 没有理由告诉它在发生高级别或树范围的冲突时支持谁的更改(如果有的话(。 例如，如果 Alice和Bob 都重命名了文件，但 Alice 将其重命名为README.txt并且 Bob 将其重命名为README.rst，则 Git 不知道该怎么做。-X参数提供给低级文件内合并代码;它不由高级文件创建、重命名或删除的合并代码使用。
因此：
为什么在这种情况下，
-Xours不只是从"我们的"分支中获取整个文件，就像处理其他冲突一样？
这不是定义-X标志的方式。 它仅适用于"低级别"冲突。
有没有办法配置
git merge以便在发生添加/添加冲突时，它确实从"我们的"分支中获取文件而不是中止合并？
不。 但是请注意，这不会中止合并：它只是使合并本身停止，并发生冲突，以便从比 Git 更聪明的人或事物那里获得帮助。 一定是你的自动化选择不在此处帮助 Git，并中止合并。