基于Trunk-Based Development的Cherry-Pick发布策略：如何正确创建Release Branch？

我们团队正在试验Trunk-Based Development工作流，通过从trunk分支cherry-pick提交来准备发布。当前开发者的工作流程如下：

• 创建feature分支（用于新功能开发、bug修复等场景）
• 工作完成并准备好评审后，提交Pull Request
• 评审通过后，以squash and merge的方式将代码合并至trunk分支
• 重复上述流程

我的核心问题是：在此工作流下，我们应如何正确创建release branch？
具体有几个方向的疑问：

• 是否应该从之前的release branch创建？
• 是否应该从trunk的特定提交节点创建？
• 或者创建孤儿分支？

思考 #

开发过程中，我们会将trunk中的提交cherry-pick到release branch，用于QA测试、功能演示、收集客户反馈等场景。这套流程目前效果不错：既减轻了开发团队的负担，又能清晰明确哪些功能会被纳入发布，还优化了流水线——不需要做开发冻结，也不用纠结代码该合并到发布分支还是热修复分支。

潜在的问题是release branch可能会与trunk产生分歧，但目前还没对我们造成实际影响。理论上，所有合并到trunk的提交最终都会被纳入当前或未来的某个release branch中。

目前我们的做法是：在trunk里选择一个既不包含下版本提交、通常也不含当前版本提交的节点，再把所有相关提交cherry-pick到新的release branch里。这种方式感觉有点笨拙，我对此存在顾虑。

另外我在考虑：从之前的release branch创建新的release branch，再从trunk中cherry-pick需要的提交是否可行？考虑到分支已经存在分歧，我暂时没发现明显的弊端。我们不会删除旧的release branch，因为它们相当于已标记的正式发布版本。从逻辑上来说，每个新版本都是基于前一版本构建的，但不确定这种方式会不会在未来引发问题。

内容的提问来源于stack exchange，提问作者Chris Hutchinson