在下面的 git-flow 之后，
对 SDLC 使用 CI/CD 方法，如果标记的提交通过了 QA 管道，那么是时候从Develop 分支创建Release 分支了，因为我的理解是，
如果 prod 管道构建在与Master 分支合并时失败，则开发人员需要首先修复该问题并在同一Release分支上创建新的工作提交。这可能会导致开发人员在开发分支中合并的代码冻结时间，因为发布分支与开发分支合并（在 prod 管道成功后）不得在开发管道中抛出错误。
我的问题是，如下图所示，
主合并持续时间是否需要开发分支上的其他开发人员的代码冻结时间？如果是，codefreeze 是否违反了持续交付的原则？
是的，我认为这种方法明显偏离了 CI 原则。它可能属于CI 剧院范围。没有 CI，你就不能真正谈论 CD。
CI 背后的总体思路是，所有开发都以小的增量更改为基础，尽可能靠近分支的尖端进行开发，并立即集成到分支中，以最大限度地提高可见性并将意外事件降至最低。只有在这种情况下，CI 工具才能有效地快速指出大多数问题提交。
在主分支继续移动时离开侧分支（无论是否冻结）意味着将该分支与主分支（在任何方向）合并的额外努力，难度与侧分支的生命周期成比例地增加。这是因为合并尝试将 2 个更大的块粉碎在一起：分支中的所有提交和自从分支被拉/同步后在 master 上完成的所有提交 - 不再是增量更改。立即识别错误提交的能力丢失了，这是一个全有或全无的决定：要么允许合并，要么接受质量打击，要么拒绝它。这就是为什么恕我直言：
发布分支与常规分支有点不同，它们在某些业务案例中是有意义的。但前提是它们通过不进行合并来保持对 CI 的忠诚。实际上，发布分支的意义在于冻结 - 将其与主干上的开发隔离开来，主干将继续向下一个版本发展。将发布分支合并回主干对我来说没有多大意义：旧版本的更改不一定与新版本兼容，这样的合并只是自找麻烦。另请参阅我对如何摆脱开发分支以简化 Git 流程的回答. 如果发布分支上有有价值的提交（请求此类合并的通常原因），则应验证它们的兼容性，并作为独立更改在主干中双重提交，提交与任何其他主干更改相同的验证标准。
注意：我并不是说非 CI 策略行不通——它们中的大多数都行得通（我与他们合作了多年），但它们更难、更慢且更昂贵。