1

遵循基于主干的开发，如下图所示：

在此处输入图像描述

假设有两个从（主干）创建的短期特征分支（f1和）。为了实现，在这种情况下，用于这些分支的源代码文件重叠。f2master

假设，有一个用于master（主干）的 CI/CD 管道在代码更改时被触发。

一种可能的代码冲突是功能性的，f1可以删除或修改f2使用....的现有源代码。这不是 VCS 冲突。

Developer1 已git commit在f1（在笔记本电脑中）执行过t，但尚未执行push

Developer2 已git commit在f2（在笔记本电脑中）上执行过t+24，但尚未执行push

据我了解，以下是笔记本电脑提交历史文件中推送前的场景：

在此处输入图像描述 给定上述场景，f1可以与 合并master，这是一个简单的快进合并。所以，master并且f1会指向156b4bf提交快照，在这次合并之后，如下图：

在此处输入图像描述 CI/CD 管道被触发，因为合并成功，没有冲突

但是当f224 小时后发生提交时，Git 将使用 3 个快照（和）执行3 路合并156b4bf，如下所示：96f5b29c435356

在此处输入图像描述如果合并成功 ，CI/CD 管道将再次触发。我的理解是，由于功能冲突，Git 应该阻止 3 路合并。

1）使用Git，快进/三向合并是否检测到功能冲突？

2) 如果是， ApartCI 是否解决了其他任何非 VCS 冲突场景？Git 不能……如果是，怎么办？

注意：没有计划使用Gitflow 工作流

4

1 回答 1

1

纯粹的功能冲突是其中 2 个冲突的更改不涉及相同的文件：

  • f1修改函数原型（比如在文件S1中）及其所有用法（比如在文件S2和S3中）
  • f2在之前未使用该函数的不同文件中添加了一个新函数用法（比如说在文件S4中），使用原始原型，因为它还没有看到f1更改

单独进行的每个更改都可以通过验证，但是当在同一个分支中集成在一起时，代码将无法工作，因为在 S4中添加的调用与来自S1的更新原型不匹配。

在这种情况下，两个合并都是快进的，并且 git 无法检测到冲突——在 3 路合并中不会有实际的文件合并，因为变更集不会触及相同的文件。因此，基于 git 的分析合并的工具（例如 gerrit）也不会检测到冲突。

只有 CI/CD 工具执行的验证才能通过发现不匹配来检测这种纯粹的功能冲突。根据使用的语言，它可能是构建/编译错误或测试/运行时/执行错误。

如果 2 项更改导致合并冲突（3 向或否），则意味着冲突是 VCS 冲突，而不是纯粹的功能冲突，是的，它将被 git 和/或基于 git 的工具检测到，因此需要在允许合并之前解决（不需要执行 CI/CD 工具来检测它）

对于您的第二个问题，ApartCI 会检测到任何一种冲突：

  • 如果是 VCS 冲突，则 2 个更改是重叠的（即它们都至少涉及一个公共源文件），因此它们不会被捆绑在一起以进行同时验证。这意味着它们永远不会最终成为一个主要捆绑包。其中一个将首先提交并最终进入项目的基线。一旦发生这种情况，其他更改将在其下一次验证尝试中修补失败，并将被拒绝。
  • 如果这是纯粹的功能冲突，则 2 个更改不会重叠，因此它们可能会或可能不会在同一个包中结束。
    • 如果它们不在同一个包中，则事件流将与 VCS 冲突的流几乎相同
    • 如果它们在同一个捆绑包中，则捆绑包验证将失败，并且遵循捆绑包拆分操作，它们最终将在不同的捆绑包中结束，并且与 VCS 冲突的事件流相同的事件流将随之而来
于 2019-01-20T19:07:58.357 回答