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 个实例，而“incoming”是具有某些实现的同一个文件。同样 - 相同的文件，显然 B 团队没有更改，但标记为冲突。

目前 B 组正在手动解决这些冲突（通常使用“接受他们的”选项），但是对于 250 多个文件，这确实很麻烦。这是怎么回事，为什么会发生这些冲突，可以采取哪些措施来防止/轻松解决这些冲突？

编辑：我确实相信 main 上使用的 squash-merges 可能是罪魁祸首，但据我所知，只有当 big-feature 从团队 A 的功能分支中获得一些更改时，它们才应该成为问题 -那么 GIT 确实会“失去”它的踪迹，因为当团队 A 提交时，源分支基本上就消失了。但是团队 B 只是直接从 main 获取东西（当然除了他们在处理自己的功能时自己的更改），main 中的更改应该有来源，不是吗？

同样，squash 合并仅在团队 A 将小 feature-branch 拉入 main 时使用，这是由 Azure DevOps PR 完成的系统.

Answer 1

如果压缩合并，则不会合并分支，而是会创建一个新的提交来代替分支。如果您随后再次合并分支，Git 无法计算合并基础并尝试再次重新合并（部分）更改，从而导致冲突。

如果您需要定期将一个分支合并到另一个分支，请不要使用压缩合并，而是定期合并。如果您使用挤压合并，则必须将所有子分支重新设置为新的挤压提交。

OP 编辑​​：
事实上，B 队在使用 main 的代码更新他们的 bit-feature 分支时并没有使用常规合并，而是一直在使用 squash-merges。因此，他们违反了此答案的最后一段，导致了各种问题。