持续融合之谜

它告诉我，在确定合并分支是否安全时，我可能会过分依赖CircleCI和GitHub Actions等CI工具的批准。

我的同事在测试中添加了新的Expect子句，以及通过它的代码。

我在同事之前修改的测试中添加了更多新条款。在剩下的一天里，我一直在努力。

接下来，两名同事回顾了我的工作，并在GitHub上批准了我的工作。 CircleCI上的所有合并前检查都通过了，包括测试和样式检查。我调整了业务基础，并决定将合并保存为早晨。

不久之后，发现与第一个同事部署的代码有关的错误。他们恢复了在第一天合并的PR。

不久之后，我再次检查了我的PR-没有合并冲突。我合并了我的代码。

一个小时左右后，另一个同事告诉我，根据CircleCI的说法，我编写的测试在主分支上失败。他们说，怎么可能？它似乎一直在传递来自它的分支！

我最近接触了该测试，所以我查看了该错误并迅速找出其含义：我添加到的测试失败了，因为其中一项期望子句依赖于已还原的代码-不再使用一个有效的期望。从主要分支机构删除相关条款后，GitHub在我的PR上没有运行新的差异；还原后的测试代码在差异中看起来只是“不变”，就好像它曾经并仍在那儿一样。

我没有删除它，也没有重新设置基准，我的PR最终重新添加了最近删除的Expect子句，即使该子句看起来没有。

一方面，该过程正在运行。有人告诉我们，有一个竞赛条件的git等效项引起合并错误，我们能够解决它。除非您担心测试可能会失败，否则为什么要在部署之前先在主分支上运行测试？

另一方面，该过程感觉像是在扰乱事物的顺序。通常会这样说：“如果您有可靠的QA和CI流程，那么如果主分支上有内容，则应该可以部署。”然而这是一个反常的案例，暗示了另外的情况。

那么，也许可以得出的教训是，我们的质量检查和CI流程不够完善。 CI是否应在幕后创建合并分支并在允许分支合并之前对此进行测试？

我不确定。同时，当我尝试决定要学习的课程时，我认为我会更经常地调整分支机构的基础。