有时候，我想告诉git在发生冲突的情况下使用某个分支的版本。
我可以通过运行以下命令来做到这一点：
git config --global merge.ours.driver true，然后添加内容为pom.xml merge=ours
是否可以执行此操作而无需更改git配置或使用.gitattributes？如果可以的话，我想内联指定它？
所以，类似
git merge develop <?? pom.xml merge=ours??>
为了提供一些背景信息，在这些特殊情况下，pom会发生冲突（我将同时更改发行版和开发版）。我正在尝试使这部分自动化，所以手动检查结果的机会有限。我不想使用.gitattributes，因为有时候我确实需要解决冲突（实际更改，而不仅仅是版本号）
答案 0 :(得分：1)
没有具有确切效果的命令行标志。
有一种 方法，但这是手动操作，暴露了merge.ours.driver中的缺陷。假设您运行git merge develop，并且pom.xml中有一个 冲突。这是您将看到的：
$ git merge develop
... message about conflict in pom.xml
$ git status
Unmerged paths:
...
pom.xml
此时，要将pom.xml解析为ours，只需运行：
$ git checkout --ours pom.xml && git add pom.xml
因为合并冲突，将pom.xml的所有三个版本放入索引，并且git checkout --ours复制了您的（HEAD）版本而不是它们的{{ 1}}，即MERGE_HEAD）版本到工作树，然后develop解决冲突。
但是，假设git add发现您您没有 更改了git merge develop，而他们 did 更改了{ {1}}。在这种情况下，Git将采用pom.xml的其版本：文件中不会出现冲突。如果没有其他冲突，您甚至没有机会用自己的pom.xml覆盖他们的pom.xml：Git将继续进行并自行提交合并。
但是即使使用pom.xml驱动程序，也会发生这种情况。如果因为我们没有触摸文件而没有冲突，那么Git只会接受他们的。 pom.xml驱动程序仅在两个分支提示相对于公共合并基础提交更改了文件时才生效。
在这种情况下，ours驱动程序比ours更强大，因此在某些情况下Git会说“自动合并”并成功，其中{{1 }}驱动程序将完全跳过合并。最终，尽管这里有几个极端的情况需要关注，ours仅处理其中一个。
最后，有两种方法可以解决此问题：
Run与-Xours合并，因此Git在提交结果之前停止。然后，您可以测试合并，并确保它是正确的；如果有必要，请在提交之前解决所有问题。
允许合并提交，但测试结果。如果错误，请立即进行修复（使用后续修订提交，或使用ours用新的和不同的合并提交替换分支顶端的合并提交）。
请注意，merge.ours.driver和修复方法和--no-commit方法都产生了一些可能称为evil merge的东西。 （有些人可能会不这样称呼，特别是如果合并本身产生了冲突，或者将产生冲突。）由您决定合并是否要比其他选择好还是坏