吉特& ApartCI-如何在邀请功能破坏之前验证代码冲突？ [英] Git & ApartCI - How to verify code conflicts before inviting functional breakage?
问题描述
基于中继的开发，如下所示：
假设有两个短期功能分支（ f1 和 f2 ）是从 master （树干）创建的。为了实现，在这种情况下，用于这些分支的源代码文件重叠。
假设，有一个CI / CD管道用于 master （trunk），它会在代码更改时触发。
一个代码可能的冲突是功能性的， f1 可能会删除或修改 f2 使用的现有源代码...。是不是VCS冲突。
Developer1已对<$ c执行 git commit $ c> f1 （在笔记本电脑中），时间为 t ，但尚未按 push
Developer2在 f2 （在笔记本电脑中）执行了 git commit 在时间 t + 24 且尚未 push
根据我的理解，以下是笔记本电脑的提交历史记录文件中的场景，在推送之前：
鉴于上述情况， f1 可以与合并master ，这是一个简单的快进合并。因此， master 和 f1 将指向 156b4bf 提交快照，如下所示：
CI / CD管道由于合并而被触发成功，没有冲突
但是当 f2 提交在24小时后发生时，Git将执行 3-使用3个快照的方式合并（ 156b4bf ， 96f5b29 和 c435356 ），如下所示：
CI / CD管道再次被触发，如果合并成功。我的理解是，由于功能冲突，Git应该阻止三向合并。
1）使用Git，前向/三向合并检测功能冲突？
2）是，是否还有其他与 ApartCI 地址？ Git无法...如果是，怎么办？
注意：没有计划使用 Gitflow工作流
纯功能冲突是其中两个冲突的更改未涉及相同文件的冲突：
- f1 修改功能原型（假设在文件 S1 中），并所有使用（例如在文件 S2 和 S3 ）
- f2 在另一个文件中添加 new 函数用法，其中该功能以前没有使用过（例如，在文件 S4 中使用了原始原型），因为它尚未看到 f1 更改
每一个孤立的变更都可以通过验证，但是当整合到同一分支中时， de将无法工作，因为 S4 中添加的调用将与 S1 中更新的原型不匹配。
在这种情况下，两个合并都是快进的，并且git无法检测到冲突-由于更改集不会接触相同的文件，因此在三向合并中将没有实际的文件合并。因此，基于git的工具（例如gerrit）可以通过分析合并来检测冲突。
只有CI / CD工具执行的验证才能检测到这种冲突通过发现不匹配而发生功能冲突。
如果2项更改导致合并冲突，则可能是生成/编译错误或测试/运行时/执行错误。3-是否）意味着冲突是VCS冲突，而不是纯粹的功能冲突，是的，它将被git和/或基于git的工具检测到，因此需要在合并之前解决（CI / CD工具执行不需要检测 ）
对于您的第二个问题，ApartCI将检测到任何一种冲突：
- 如果是VCS冲突，则两个更改是重叠的（即它们都至少接触一个公共源文件），因此它们不会成为捆绑以便同时进行验证。这意味着它们永远不会以主捆绑包结尾。其中一个将提交并最终到达项目的基准。一旦发生这种情况，其他更改将无法在其下一次验证尝试中修补，并且将被拒绝。
- 如果是纯粹的功能冲突，则这两个更改不会重叠，因此它们可能会或可能不在同一个包中。
- 如果它们不在同一捆绑中，则事件的流向与VCS冲突的流向几乎相同
- 如果它们在同一个捆绑软件中，则捆绑软件验证将失败，并按照捆绑软件拆分操作它们最终将以不同的束结束，并且再次发生与VCS冲突相同的事件流
Following Trunk Based Development, shown below:
Assume there are two short-lived feature branches(f1 and f2) created from master(trunk). For implementation, source code files used for these branches overlap, in this scenario.
Assume, there is one CI/CD pipeline for master(trunk) that gets triggered on code change.
One code conflict that can be possible is functional, f1 could remove or modify existing source code that f2 uses.... This is not a VCS conflict.
Developer1 has perform git commit on f1(in laptop) at time t and yet to push
Developer2 has perform git commit on f2(in laptop) at time t+24 and yet to push
As per my understanding, below is the scenario in commit History file of laptop, before push:
Given above sccenario, f1 can get merge with master, which is a simple fast-forward merge. So, master and f1 will point to 156b4bf commit snapshot, after this merge, as shown below:
CI/CD pipeline gets triggered, as merge is successful, with no conflicts
But when f2 commit happens after 24 hours, Git will perform 3-way merge using 3 snapshots(156b4bf, 96f5b29 and c435356), as shown below:
CI/CD pipeline gets triggered again, if merge is successful. My understanding is, Git should block 3-way merge due to functional conflict.
1) Using Git, Does fast-forward/3-way merge detect functional conflict?
2) If yes, are there any other non-VCS conflict scenarios that ApartCI address? that Git cannot... if yes, how?
Note: No plan to use Gitflow workflow
A purely functional conflict is one in which the 2 conflicting changes don't touch the same files:
- f1 modifies a function prototype (let's say in file S1) and all its usages (let's say in files S2 and S3)
- f2 adds a new function usage in a different file in which the function wasn't used before (let's say in file S4), using the original prototype since it doesn't yet see the f1 change
Each change takes in isolation could pass verifications, but when integrated together in the same branch the code won't work as the invocation added in S4 won't match the updated prototype from S1.
In such case both merges are fast-forward and the conflict can not be detected by git - there will be no actual file merges in the 3-way merge since the changesets don't touch the same files. Thus neither will the conflict be detected by git-based tools analyzing the merge, for example by gerrit.
Only the verifications performed by the CI/CD tool can detect such purely functional conflict by finding the mismatch. Depending on the language used it'd be either a build/compilation error or a test/runtime/execution error.
If the 2 changes cause a merge conflict (3-way or not) it means the conflict is a VCS one, not a purely functional one and yes, it would be detected by git and/or git-based tools, so it would need to be addressed before the merge is allowed (a CI/CD tool execution would not be necessary for detecting it)
To your 2nd question ApartCI would detect either kind of conflict:
- if it's a VCS conflict the 2 changes are overlapping (i.e. they both touch at least one common source file) so they won't be bundled together for simultaneous verification. Which means that they will never end up in a primary bundle together. One of them will be committed and end up in the project's baseline first. As soon as that happens the other change will fail patching in its next verification attempt and will be rejected.
- if it's a purely functional conflict the 2 changes are not overlapping, so they may or may not end up in the same bundle.
- if they are not in the same bundle the flow of events will be pretty much the same as that for a VCS conflict
- if they are in the same bundle the bundle verification will fail and following the bundle splitting actions they will eventually end up in different bundle and again the same flow of events as that for a VCS conflict will follow
这篇关于吉特& ApartCI-如何在邀请功能破坏之前验证代码冲突？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
