Git 吉特公司；ApartCI-如何在引发功能中断之前验证代码冲突？

以下是基于主干的开发，如下所示：

---

假设有两个短期的特征分支（

f1

和

f2

）是从

master

（主干）创建的。为了实现，在本场景中，用于这些分支的源代码文件重叠

假设，

master

（trunk）有一个CI/CD管道在代码更改时被触发

---

一种可能的代码冲突是功能性的，

f1

可以删除或修改

f2

使用的现有源代码。。。。这不是VCS冲突

Developer1在时间

t

时对

f1

（在笔记本电脑中）执行

git提交

，但仍要

推送

Developer2在时间

t+24

时对

f2

（在笔记本电脑中）执行

git commit

，但仍要

push

---

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

鉴于上述scenario，

f1

可以与

master

进行合并，这是一种简单的快进合并。因此，

master

和

f1

在合并后将指向

156b4bf

提交快照，如下所示：

当合并成功且没有冲突时，将触发CI/CD管道

但是，当24小时后发生

f2

提交时，Git将使用3个快照（

156b4bf

，

96f5b29

和

c435356

）执行3路合并，如下所示：

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

---

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

2） 如果是，是否有其他非VCS冲突场景可以解决？那个笨蛋不能。。。如果是，如何进行

---

注意：没有计划使用

A纯功能性冲突是指两个冲突的更改不涉及相同的文件：

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

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

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

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

如果这两个更改导致合并冲突（三向或非三向），则表示冲突是VCS冲突，而不是纯粹的功能性冲突。是的，它将被git和/或基于git的工具检测到，因此需要在允许合并之前解决它（检测它不需要执行CI/CD工具）

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

• 如果是VCS冲突，则这两个更改是重叠的（即，它们都至少接触一个公共源文件），因此它们不会同时进行验证。这意味着他们永远不会在一起。其中一个将被承诺并最终进入项目的第一阶段。一旦发生这种情况，另一个更改将在其下一次验证尝试中失败，并将被拒绝
• 如果这是一个纯粹的功能冲突，那么这两个更改不会重叠，因此它们可能会或可能不会在同一个捆绑包中结束。
  • 如果它们不在同一捆绑包中，事件流将与VCS冲突的事件流几乎相同
  • 如果它们在同一个捆绑包中，捆绑包验证将失败，随后它们将最终在不同的捆绑包中结束，并且再次出现与VCS冲突相同的事件流

---

Dan在这里以C语言为例。。。当他说。。。函数原型和定义…针对您的观点。。。“不会有三方合并”，我对此有点怀疑。。。3路合并发生在f2提交之后。不会基于相同/不同的文件策略调用三向合并。。3路合并是根据主服务器和f2（需要合并的任何分支）之间的路径（直接/间接）调用的。对不起，

将不会有3路合并

我的意思是，在这种情况下，技术上不会合并任何文件，只会选择不同版本的文件。是的。。。。标准是。。。为了检测冲突。。。我不需要工具来解决冲突。。。不是吗？人为干预更好。。。。它说…合并冲突自动化是非常危险的，这将完全排除自动化的可能性。。。。。ApartCI是在检测冲突还是检测并解决冲突？@DanCornilescu首先。。。对于场景，在查询中给出。。。三方合并是否检测到非VCS冲突？