今天例行检查PR合并，发现早上有两个PR被合并到了release分支，而这个release分支的代码原本已经通过了QA验收，计划明天要发布生产环境。这就有大问题了，可惜我们的开发人员还没意识到这其中存在的问题，否则他们不应该去approve这样的PR。

“对代码做任何改动，都可能会导致系统不稳定！！！”。

很简单的道理，但是很多人却不知道或者存在侥幸心理，觉得只是改动了一点点，不会有什么问题，结果上线后才发现大问题。

为了应对这样的问题，早些年的一个通行做法就是code freeze（代码冻结），在测试验收后，代码冻结，不允许修改，除非紧急的hot fix。

这样做当然有效果，但是也有不少副作用：代码冻结阶段不能合并代码协作不便利，要严格控制成本相对比较高，是否能合并的标准难把握。

于是后来在这基础上，就演变成了测试验收后，创建release的分支，master分支可以继续开发继续合并代码，如果有hot fix，就在release 分支上进行。

那么像开头说的那种随意往release分支合并代码，造成的问题就是本来测试稳定的分支代码又不稳定了，重新回归测试就要延期部署，强行部署生产环境可能会导致很大风险。

所以遇到这种情况下，通常有两种解决方案：
1. 如果这两个PR真的很重要很紧急，那么我们延期部署，QA需要重新做一次回归测试，发现了任何bug，在release分支中修复，最后把代码合并会master分支。回归测试通过后，才能发布。
2. 如果这不是紧急的更新，那么Revert这两个合并到release分支的PR，PR只合并到master。

最后将问题拿到站立会议中讨论，大家一致认同第二种方案。

#软件工程之美#