有一个使用github存储库的项目。当合并拉取请求之前存在要解决的冲突时，大约90％的冲突案例只涉及一个包含已完成票证列表的CHANGELOG文件，例如：
## current
<<<<<<< HEAD
ISSUE-128 done some 128
ISSUE-131 done some 131
=======
ISSUE-125 done some 125
>>>>>>> ISSUE-125
ISSUE-126 done some 126
ISSUE-120 done some 126
ISSUE-123 done some 126
我想知道是否有办法自动合并这个特定文件（可能通过使用ie gitignore格式提供一些配置）和一个简单的规则来接受来自双方的更改（至于订单足够的变化将是紧挨着彼此，知道怎么可能控制顺序是次要的但有趣的）。附加规则可以是验证每一方是否总是只有一个添加，然后继续自动合并。
理想情况下，在github上进行此类配置，即使本地git解决方案也会有所帮助。
答案 0 :(得分：1)
[答案，稍微修改一下。]
这里你想要的通常称为 union merge ，这实际上是内置于Git中的。它很少做正确的事情，但对于这种特殊情况，union merge实际上可能正确。您可以使用.gitattributes为特定文件名设置联合合并。有关详情，请参阅git merge, keep both。
实际上，我唯一担心的是，对于一个更复杂的＆＃34;冲突我宁愿看到合并存在冲突
正确：我认为联合合并的主要问题是总是成功，即使合并结果是荒谬的。您需要记住它是以这种方式设置的，并且每次都要小心检查合并结果。
（就个人而言，如果Git把它拆分成一个单独的＆＃34; resolve＆＃34;命令可以在每个文件上调用，我个人会更高兴。我认为git merge-file命令实际上，这里大多是人们想要的，除了使用起来很痛苦。使用更有用的界面，而不是-X ours和-s ours以及-X theirs等等，以及.gitattributes中的各种合并驱动程序，我们可以让合并冲突发生，检查它们，确定哪些方面可以保留，如果满足，并继续使用。当然，如果在这条路上走得更远，最终得到一个GUI合并工具......）
答案 1 :(得分：0)
这个问题经常发生;除了Changelog样式文件之外，如果您拥有源文件并添加新内容，也会发生这种情况 - 大多数情况下，您会在某些规范位置添加新方法或其他内容（例如靠近文件末尾），并且在合并后每次都表现为冲突。
简短的回答：git在这里无法帮助你，也没有任何其他自动合并工具，缺乏真正的人工智能。在其他地方提到了union驱动程序，但是，坦率地说，即使对于Changelog文件，这对我来说也是危险的。您可以使用自定义合并驱动程序来理解您的更改日志格式，但这样做可能会让您不再接受这个想法（如果是这样，gitattributes联机帮助页可以为您提供更多信息）。
侧面回答/提示：我在源文件中有这样的评论取得了一些成功：
def lastmethodinclass
...
end
## placeholder 1 ##
## placeholder 2 ##
## placeholder 3 ##
end # class
然后，在第一个分支中，我将一个新方法放在＆＃34;占位符1＆＃34;之后。如果我后来记得，在另一个分支中，我已经用完了＃34;第一个占位符，我把我的下一个方法放在第二个占位符之后，等等。
这仍然很尴尬，但它可以避免那些讨厌的冲突。我会不时清理掉合并后累积的旧占位符，并将它们放回原来的位置。
与其他人一起编码时没用，是的。