Git 工作流问题 - 文件未更改的大量合并冲突

Question

以下是我们团队正在使用的工作流程:

• main分支，其中特征分支被压缩合并;这是由团队A处理
• big-feature分支，B组使用的main分支
• 团队B将有来自big-feature的更小的特性分支;当他们将功能分支拉入big-feature
时，他们正在使用常规的快进合并。

问题:每隔一段时间团队B想要从main到他们的big-feature的最新更改。所以他们做了以下操作:

• 从原点获取所有更改，并将所有更改拉到本地main
从big-feature创建merge-with-main分支
• 合并main到merge-with-main

现在，我希望他们应该只在他们已经更改的文件中得到冲突，这些文件也在main上更改了。然而，他们目前有超过250个合并冲突，其中大多数(如果不是全部)都在他们根本没有更改的文件中。看看Visual Studio中的冲突，很明显是"他们的"。例如，当存根文件提交到main分支时，文件的初始版本包含大量NotImplementedException实例，并且"传入";是带有一些实现的相同文件。同样的文件，显然没有被B组更改，但标记为冲突。

目前团队B正在手动解决这些冲突(通常使用"take their "选项)，但对于250多个文件来说，这真的很麻烦。这里发生了什么?为什么会发生这些冲突?如何预防/轻松解决这些冲突?

编辑:我相信main上使用的压缩合并可能是罪魁祸首，但我敢说，只有当big-feature从团队a的功能分支中获得一些更改时，它们才应该是一个问题-然后GIT确实会"失败"。跟踪它，因为当团队A提交时，源分支基本上就消失了。但是B团队只直接从main获得东西(当然除了他们自己在开发自己的功能时所做的更改)，main

的更改应该有一个来源，不是吗?同样，压缩合并仅在团队A将小feature-branch拉入main时使用。，这是由Azure DevOps公关系统完成的。

Answer 1

如果您压缩合并，那么分支不会合并，但是会在分支的位置创建一个新的提交。如果您随后再次合并分支，Git将无法计算合并基数，并试图再次重新合并(部分)更改，从而导致冲突。

如果您需要定期地将一个分支合并到另一个分支中，请使用而不是使用压缩合并，而是常规合并。如果你使用压缩合并，你必须将所有的子分支重新定位到新的压缩提交上。

OPs EDIT:
事实证明，B团队在使用main的代码更新bit-feature分支时，实际上并没有使用常规合并，而是一直在使用压缩合并。因此，他们违反了这个答案的最后一段，导致了各种各样的问题。