【发布时间】：2010-08-31 19:43:37
【问题描述】：
Branch per Release 与 Code-Promotion Branches 策略的优缺点是什么？
【问题讨论】：
【发布时间】：2010-08-31 19:43:37
【问题描述】：
main reason why you branch 用于隔离开发工作。
所以这真的取决于你认为最重要的隔离：
- 针对给定版本的推广工作（将隔离该推广步骤中的提交：测试、集成或产品/修补程序）
- 发布工作（包括单元测试、集成、生产阶段一个接一个）
代码推广允许在每个版本中进行并行推广工作（您开发 n+2，同时测试 n+1 并维护 n）。
虽然每个版本的分支允许更简单、更顺序的开发周期，但您主要在开发 n+1 时测试和维护 n。
无论选择什么策略，您都需要解决 n 和 n+1 之间的同步步骤（什么以及何时合并从 n 到 n+1 的进化？）：
- 使用 Code-Promotion，您可以在不同的步骤合并
- 使用每个版本的分支，您通常只从一个版本合并到另一个版本的当前开发状态。
所以基本上，代码提升策略意味着更多的分支、更多的合并和更精确的历史记录被保存和隔离在这些分支中。
但这也意味着更多的设置和管理环境。
每个版本的分支更简单（前提是您能够知道您正在处理的内容实际上最终会成为下一个版本的一部分）。
【讨论】：
-
在每个版本的分支场景中，是什么阻止了您在测试 n+1 和维护 n 时开发 n+2？
-
@vlf nothing：在代码升级中它只是更详细（即“更多分支”），因为您将代码从功能分支升级到集成分支再到给定版本的发布分支
n. -
Sooo，当您说“代码推广允许每个版本进行并行推广工作”时，您会受到不必要的限制（两者都允许），而当您说“每个版本的分支允许更简单的顺序在开发 n+1 时主要测试和维护 n 的开发周期”，您暗示每个版本的分支不允许在两个以上的分支上进行活动，这显然是不正确的。
-
@vlf 你想太多了。您可以根据需要调整和调整这两个工作流程。