Brtdku

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