这种情况会触发3 way merg的冲突么？

请看下图。假设有ABC三个文件。 张三负责master 李四负责bugfix分枝。然后张三在C4 修改了A 文件，李四在C3也修改了A文件，当李四merg到C5时显然会产生冲突。必须要决定A文件到底是用张三版？还是用李四版？还是同时接受两人的修改。这是教案给出冲突的例子

但是假设张三在C4 修改了B文件，李四在C3修改了C文件。当李四merg到C5时 B文件是继续用C2版本的？还是用C4版本的？这算不算冲突？

如果第二种情况算冲突，那么它在现实中出现的概率一定比第一种冲突出现的概率大。因为考虑到工程文件特别多的时候，每次提交修改的比例不会特别多。这就导致张三和李四修改出现重叠的情况不容易发生。那么第二种情况就几乎必然发生。可是这样就会导致以下情况发生。李四在分枝上测试没有问题，一merg就出现冲突，然后李四就要决定如何处理冲突，处理完以后如果有bug，李四就还要回到bugfix分枝继续修改，测试。测试没问题，master分枝又提交了新版本，又有几个老文件被修改了。导致李四merg又报冲突。这样李四就很难merg到master上了。这种情况怎么处理呢？

第二种情况也可以被认为是冲突，因为李四的修改与张三的修改在同一文件上产生了冲突。在这种情况下，解决冲突的最好方法是由李四手动解决冲突，并在确认修改后再次提交。

对于李四来说，他需要从 Master 分支中将最新的修改拉取到 Bugfix 分支上，然后手动解决冲突并提交解决方案。在此之后，他需要重新运行测试确保没有出现新的问题。如果测试没有问题，他就可以继续将修改提交并将 Bugfix 分支合并到 Master 分支上。如果还要继续在 Bugfix 分支上工作，他将需要在提交之前再次从 Master 分支中拉取新的修改，并重复这个过程。这个过程可能会比较繁琐，但它确保了李四的修改在合并到 Master 分支前已经经过充分的测试和检查，从而减少了可能出现问题的风险。

在现实工作中，是否存在Master更新过于频繁。导致李四反复从Master拉取代码反复测试反复改bug就是无法合并到master的情况。遇到这种情况实际工作中如何处理？有什么经验可以分享么？

bugfix测试通过----拉取master-----运行报错-------改bug------测试通过----发现master又更新了-----------拉取master------运行测试报错--------改bug--------测试通过--------------发现master又更新了----------拉取master………………………………