Git＆ApartCI - 如何在邀请功能破坏之前验证代码冲突？

Posted 2023-02-21

【中文标题】Git＆ApartCI - 如何在邀请功能破坏之前验证代码冲突？

【英文标题】：Git & ApartCI - How to verify code conflicts before inviting functional breakage?

【发布时间】：2019-06-13 17:39:03

【问题描述】：

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

---

假设从master(trunk) 创建了两个短期 功能分支（f1 和f2）。为了实现，用于这些分支的源代码文件重叠，在这种情况下。

假设，master(trunk) 有一个 CI/CD 管道，在代码更改时触发。

---

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

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

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

---

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

给定上述场景，f1 可以与master 合并，这是一个简单的快进合并。所以，master 和f1 将指向156b4bf 提交快照，合并后如下图：

CI/CD 管道被触发，因为合并成功，没有冲突

但是当f2在24小时后提交时，Git会使用3个快照（156b4bf、96f5b29和c435356）执行3路合并，如下图：

CI/CD 管道再次触发，如果 合并成功。我的理解是，由于功能冲突，Git 应该阻止 3 路合并。

---

1) 使用 Git，快进/3 路合并是否检测到功能冲突？

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

注意：没有计划使用Gitflow workflow

【问题讨论】：

@DanCornilescu 首先...对于场景，在查询中给出... 3-way merge 是否检测到非 VCS 冲突？

【参考方案1】：

纯粹的功能性冲突是指 2 个相互冲突的更改不会触及相同的文件：

f1

修改函数原型（比如在文件

S1

中）和

所有

用法（比如在文件

S2

中和

S3

)

f2

在之前没有使用过该函数的不同文件中添加了一个

new

函数用法（比如在文件

S4

中），使用原始原型，因为它还没有看到

f1

变化

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

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

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

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

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

如果是 VCS 冲突，则 2 个更改是重叠的（即它们都涉及至少一个公共源文件），因此它们不会被 bundled 同时验证。这意味着他们永远不会在一起primary bundle。其中一个将被提交并首先出现在项目的baseline 中。一旦发生这种情况，其他更改将无法在下一次验证尝试中修补并被拒绝。 如果这是纯粹的功能冲突，则 2 个更改不会重叠，因此它们可能会或可能不会在同一个包中结束。 如果它们不在同一个包中，则事件流将与 VCS 冲突的事件流几乎相同 如果它们在同一个捆绑包中，捆绑包验证将失败，并且遵循bundle splitting actions，它们最终将位于不同的捆绑包中，并且将再次遵循与 VCS 冲突相同的事件流

【讨论】：

Dan在这里以C语言为例...当他说...函数原型和定义...

对于您的观点...“不会有 3 路合并”，对此我有点怀疑... 3 路合并发生在 f2 提交之后。 3路合并不会基于相同/不同的文件策略调用.. 3路合并是基于master和f2（任何需要合并的分支）之间的路径（直接/间接）调用的。

抱歉，there will be no 3-way merge 我的意思是在这种情况下，技术上不会合并任何文件，只是会选择不同版本的文件。

是....标准是...只检测冲突...我不需要解决冲突的工具...不是它？人工干预更好......

Here 它说...合并冲突自动化的风险很大，这将完全排除自动化的可能性.....ApartCI 是在尝试检测冲突还是检测和解决冲突?