我听说它提到您可以创建自己的策略来检测合并冲突。 This question, for instance, suggests that it's possible。我想尝试一下，但是根本找不到任何进一步的信息。
我了解我需要创建一些可执行文件并将其放在路径中-没问题-但是将传递给此可执行文件的内容以及输出的内容
答案 0 :(得分：2)
合并策略是git merge -s选择的策略。您是正确的，您只需要将可执行程序放入$PATH（或Git的git-core目录，git前端将其添加到$PATH中）。 / p>
问题在于编写合并策略并不是一件容易的事（实际上，这通常很难）。 Git传递的参数没有记载。您必须从Git来源中找出它们，并意识到它们可能会在将来的Git版本中更改。其中一些秘密存储在环境变量中-特别是，您可以附加到合并所涉及的提交中的图例位于环境变量中，其中包含有问题的提交的哈希ID。
（我自己没有编写合并策略，也没有任何其他建议，除了：使用GIT_TRACE=1 git merge -s <strategy>来调用您的策略以查看argv元素是什么。隐藏的环境变量曾经公开git stash脚本中，但git stash已用C重写。）
您的合并策略的工作是更新Git的索引以保存合并结果，然后以零状态退出（成功）；否则，以非零状态（通常为1）退出以指示失败。如果您希望对用户友好，那么也建议根据任何成功的合并结果来更新工作树。可能会有一个特殊的退出状态，表示“甚至没有尝试合并”（与“合并失败，我留下一团糟供人类完成合并”），但是也没有记录。
内置的一组合并策略是：
git-merge-recursive：git merge -s recursive调用了这个；这是大多数人最熟悉的一种。git-merge-resolve：git merge -s resolve调用它。它实际上是与git merge-recursive相同的程序，只是在存在多个合并基础提交时，它所做的事情有所不同。git-merge-octopus：虽然git merge -s octopus调用了此选项，但是缺少一个git merge选项但又提及多个的-s -承诺合并。git-merge-ours：git merge -s ours调用此。git-merge-subtree：git merge -s subtree调用它。像git-merge-resolve一样，只是git-merge-recursive的一种变体。如果您不传递-s参数，除非您命名两个或多个提交参数，否则Git将使用-s recursive。
从上面的列表中可以看到，实际上Git内置了三种策略：章鱼，我们的策略和“其他所有策略”。章鱼策略根本不处理合并冲突，-s ours完全忽略了所有其他输入提交，这使得其代码相对简单，因此大部分艰苦的工作都在剩下的单个合并策略中。