如何使用基于主干的开发精选发布策略准备发布分支

问：

我正在和我的团队一起试验一个基于主干的开发工作流程，我们通过从主干分支中挑选提交来准备版本。开发人员的工作流程基本上是：

1. 创建功能分支（用于新功能/错误修复/等）
2. 一旦工作完成并准备好进行审查，就会提出拉取请求
3. 审核通过后，挤压并合并到主干分支
4. 重复

我的问题是：我们如何使用此工作流正确创建发布分支？

从上一个版本分支？
来自特定提交？
从无到有（孤儿分支）？

思潮

在整个开发过程中，我们挑选提交到发布分支中（用于 QA、演示使用、客户反馈等）。这个过程运行良好，因为它最大限度地减少了开发团队的负担，而且我们确切地知道哪些功能可以将其纳入版本。它改进了我们的管道，因为团队不需要参与开发冻结和/或关心合并到正确的（发布/修补程序）分支中。

一个潜在的缺点是释放与树干发散的分支，但到目前为止，这对我们来说并不是一个问题。原则上，每个进入主干的提交都会进入当前或未来的发布分支。

到目前为止，我们一直在通过在主干中选择一个不包含下一个版本的提交来弥补到期，并且通常不包含当前版本的提交或很少提交，然后我们将所有相关内容挑选到发布分支中。这似乎很笨拙，我有顾虑。

从以前的发布分支创建一个发布分支，然后从主干中挑选，这有意义吗？考虑到分支已经发散，我没有看到缺点。我们从不打算删除发布分支，因为它们实际上是我们标记的版本。从某种意义上说，每个版本都基于以前的版本，这是合乎逻辑的，但我们不确定我们不会在未来制造问题。