问题描述
想知道在将更改推送到生产环境时，是否应该使用发布分支，还是直接从主分支上发布更改。他还提到，在开发人员完成功能分支上的更改、自动化测试、代码审查并将更改合并到主分支后，仍然需要进行一定量的手动测试。用户想知道推荐的做法是什么。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
根据《Accelerate》一书的研究，使用较少的长期分支的团队更加成功。因此，问题是对于给定的团队，最佳的最小分支集是什么。答案是“因情况而异”。每天推送十几次到生产环境的团队通常会选择从主分支上发布，而每个迭代周期发布一次到集成测试环境并在上线之前停留一周的团队通常会选择两个分支。
个人经验是，如果需要，随时可以添加分支，但删除分支非常困难。因此，为了尽量减少分支数量，我建议经常发布的小团队始终从应用于主分支的标签上发布。如果确实需要创建一个短期的补丁发布分支，从上次发布的标签创建分支非常容易。关键是希望这种情况是例外而不是规则，这也是上述书中的研究结果。
我见过很多团队使用两个分支的方法。常见的方法有：
1. 将代码集成到“develop”分支并部署到集成测试环境。然后将经过签署的工作从主分支中挑选出来，标记为发布。
2. 将代码集成到“master”分支并部署到测试环境。然后将经过签署的工作挑选到一个长期的“release”分支中，然后标记为发布。
这两种方法实际上是相同的。采用这种“两个分支”的方法是为了能够独立发布和重新排序功能。
方案2
使用拉取请求构建和测试是一种常见的做法，可以减少分支合并的复杂性和风险。
一种常见的做法是在拉取请求到主分支后进行构建和测试。开发人员创建功能分支，并在完成后向主分支提交拉取请求。这将触发基于拉取请求的构建作业。
例如，如果您使用的是Github和Jenkins，您可以使用Github拉取请求插件，在提交到主分支时运行Jenkins作业。如果通过了测试，然后进行代码审查和手动测试。
方案3
这取决于您对发布策略的期望和需求。
如果您对使用功能分支感到满意，那么意味着您也接受了可能复杂的分支合并以及它们给主分支带来的风险：故障、延迟等。
如果您有严格的发布截止日期，那么直接从主分支发布可能会很困难，因此可以在需要的功能分支合并到主分支后，从主分支上创建发布分支，这样可以通过隔离它与未来发布的更改来稳定发布代码库。较小的更改和较低的提交频率应该显著降低与主分支相比的风险。
发布分支还允许您为客户提供发布的热修复和复杂的发布故事：同时支持多个发布、主要/次要/增量发布等。如果直接从主分支发布，要实现这些将非常困难，甚至不可能。
使用发布分支的缺点：
– 每个发布分支都需要维护资源，您的团队必须在主分支和发布分支之间分散注意力（它们会分叉），切换上下文可能不容忽视。
– 在发布分支或主分支上发现的问题，但也影响到发布分支（因为分支分叉），可能必须在每个受影响的分支上单独开发和提交修复（因为分支分叉，修复可能在所有分支上不完全相同）。
如果发布分支提供的优势对您没有兴趣，或者如果它们的缺点对您来说是致命的，并且您对于您的发布“现状/接受或离开”满意，那么只需使用选定的主分支参考点作为发布候选，并且如果它们符合您的发布质量标准，则将其标记为发布。如果之后发现任何与发布相关的问题，只需等待包含修复的后续发布（但它可能还包含其他内容）。
这种方法的主要缺点是在主分支中的变更速度很快的情况下，很难选择发布候选。找到好的候选者的机会可能非常低。如果您找不到任何候选者怎么办？试图限制进入主分支的提交速度以在发布之前稳定它将导致集成延迟（功能在其开发分支孤立的时间比绝对需要的时间更长），越来越复杂的分支合并，最终导致所有未来发布的延迟/滑坡。
选择较小的恶。这就是为什么我喜欢持续集成的原因-至少复杂的合并不在考虑范围内。发布策略的考虑仍然适用于CI-在集成完成后，发布策略开始生效-但是这两个恶劣的选择“不那么糟糕”：）根据我的经验，显著减少。并且在使用具有门控CI系统的情况下，可以保持主分支的稳定性，而不受提交速率的影响。