合并Lightswitch分支时，同事通常会向我也修改过的实体添加属性，这将导致合并冲突，因为新的XML条目会添加到lsml文件中的相同位置
我可以通过不按特定顺序接受左和右来有效地解决这些问题，因此一个优先于另一个，因为在这些特定情况下顺序并不重要。在极少数情况下，这是无效的，这将在项目中产生错误，我认为这是一种风险（但没有遇到）
有没有办法（最好是文件扩展名）让git自动接受同一位置的源和目标更改，并简单地将一个放在另一个下面
总的来说，这很难做到
有些人尝试使用Git的union merge（现在比早期更容易访问；正如在那个问题中，您只需在.gittributes文件中添加merge=union），但这通常不起作用。有时它可能会起作用。如果您的XML始终是结构化的，以使面向行的联合合并生成有效的XML（基本上，将整个XML子元素都放在一行上），并且总是添加整个新的XML子元素，那么将它进行大量的简化是有效的
在Git中，可以编写自定义合并驱动程序。为XML编写一个有用的工具是很困难的
首先，我们需要一个XML差异引擎，如Sylvain Thénault的xmldiff，为三个XML文件（合并基、本地或--我们的，以及其他或--他们的文件：差异基与本地和基与我们的）构建两个字符串到字符串（或树到树）的编辑。这一个看起来与Python的difflib类似。（然而，由于参考文献的原因，它似乎产生了树移动/嵌套级别的操作以及简单的插入和删除操作。这对于树到树编辑算法来说是一件自然而合理的事情，在这里可能实际上是可取的。）
然后，给定两个这样的差异，我们需要代码来组合它们。union方法是忽略所有删除：只需将所有添加添加到基本版本（或者，等效地，将“其他”添加到“本地”，或将“本地”添加到“其他”）。我们还可以将树插入/删除操作与“真实”（非联合样式）合并结合起来，甚至可以声明冲突。（允许对树嵌套级别的更改进行不同的处理可能会很好，这种更改是由类似DTD的东西驱动的。）
就我所知，这些最后的部分在任何地方都没有完成。除此之外，我在这里链接的Python xmldiff是一个相当大的代码块（我没有仔细阅读它，也没有尝试安装它，我只是下载了它并略读了一下，它实现了类似Myers的算法和斯坦福论文中更为奇特的“快速匹配/编辑脚本”算法）