我听说您可以创建自己的策略来检测合并冲突。 This question, for instance, suggests that it's possible。我想试一试，但我找不到任何进一步的信息。
我知道我需要创建一些可执行文件并将其放在路径中 - 没问题 - 但是将传递给这个可执行文件的内容，以及它应该输出什么
【问题讨论】：
标签： git
合并策略是由git merge -s 选择的策略。没错，您只需将可执行程序放入您的 $PATH（或 Git 的 git-core 目录，git 前端将其添加到 $PATH）。
问题在于，编写合并策略并非易事（事实上，总的来说它非常困难） 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 中实际上只有三种策略：octopus、ours 和“everything else”。 octopus 策略（根本）不处理合并冲突，-s ours 完全忽略了所有其他输入提交，这使得它的代码相对简单，因此大部分工作都在单个剩余的合并策略中。
【讨论】：