这个问题与某个版本控制程序无关。
假设在某些分布式版本控制下有源代码树。我们称之为A.
在某些时候，别人克隆它并获得自己的副本。我们称之为B。
即使某些版本控制工具对分支有不同的定义（有些可能会调用A和B存储库），我也会调用A和B分支。
我们假设分支A是“主”分支。在分布式版本控制的上下文中，这仅意味着分支A被更加主动地修改，而分支B的所有者定期同步（拉取）来自分支A的新更新。
让我们考虑分支B中的某个源文件包含一个类（同样，它也是语言不可知的）。分支B的所有者认为某些类方法更合适，并通过在类体内移动它们将它们组合在一起。功能上没有任何改变 - 这是一个非常简单的重构代码。但这种变化反映在差异中。现在，假设从分支B的这种变化永远不会合并到分支A中，分支B的所有者在从分支A拉出并合并到他自己的工作空间时总是会得到这种差异。即使只有一个这样微不足道的变化，分支B的所有者每次从分支A拉出时都需要解决冲突。只要分支A和B被独立修改，就会出现越来越多这样的冲突。这种情况的解决方法是什么？分支B的所有者应遵循哪个工作流程以最小化定期与分支A同步的工作量？
答案 0 :(得分：2)
分支机构B的所有者应该与分支机构A的所有者讨论这一变化。他们应该已经决定改变是否值得进行，在这种情况下它应该已经被提交到主干（A）或者它不是' t，在这种情况下应该从未制作过。 VCS不能替代开发人员之间的通信。
答案 1 :(得分：1)
Dev B应该让Dev A离开他。
如果两个分支发散并且从不收敛，情况就无法避免。它类似于项目中的一个分支 - 很难合并两个不同的分支。
答案 2 :(得分：0)
Dev B应该重新解析，或者添加一些有意义的功能，这些功能有足够的动力来保证合并回A.否则告诉他“他们是休息”。
举一个极端的例子，他可以决定他不喜欢C并决定一行一行地重写所有的Pascal，使用相同的变量名，类名等。到了这一点唯一的区别是语言。那么，当他坚持认为没有任何变化时，你会告诉他什么，所以应该没有差异？
答案 3 :(得分：0)
一个解决方法是围绕代码比较创建一个奇特的diff包装器，它将智能地忽略某些非常特定的差异。
在一个简单的层面上，它通常通过gdiff实现，在发烧友身上，使用自定义差异代码。
但是，我必须说这种情况确实是一件坏事，并且将更改合并到A中会更好 。例如，向A的维护者所有者提交补丁