Subversion 分支和发布计划 [关闭]

Question

目前我们正在为我们的项目遵循一个简单的发布计划，如下所示；

1. 开发人员已将更改提交到 subversion 存储库。
2. 构建对 QA 服务器的更改。
3. 构建对生产服务器的更改。

问题是我们在 SVN 主干中使用一个单一的源代码集来完成所有这些步骤。

因此我们无法控制 QA 服务器的发布（例如：避免某些要求）。

我们的发布事件非常复杂，因为有时我们必须向 QA 服务器发布 5-6 次。

我想使用颠覆分支我可以克服这个问题。希望我可以为 QA/live 服务器发布创建一个单独的分支，并且我可以合并来自 head/trunk 的必要更改。

或者这是相反的方式？为 QA/live 服务器版本保留 head/trunk 版本，并为开发提交创建一个分支。

正确的方法是什么？

请让我知道是否有更好的方法/工具来处理这种情况。

谢谢。

Answer 1

在 SVN 中有一种非常流行的分支方法。这里有描述：http://svnbook.red-bean.com/en/1.7/svn.branchmerge.commonpatterns.html

在我的项目（具有单独发布周期的单人项目）中，我同时使用发布和功能分支，没有任何问题。

确切的分支政策可能会有所不同，这对我有用：

• Trunk（只有一个）：所有自动测试通过，仅包含已完成的功能和错误修复
• 功能分支（通常是多个）：专用于单个功能或错误修复，通常构建，自动测试通常通过，完成后重新集成到主干并删除
• 稳定分支（可能是多个，但通常是一个）：专用于计划发布，自动测试通过，用于生成要发送给 QA 的构建，从中创建内部/外部发布标签，一些修复甚至功能可以从主干合并到这里

Answer 2

正确的方法是什么？

这是一个意见，但创建 3 个树干。一种用于开发，一种用于 QA，一种用于生产。

只有在 fork 项目时才需要开发分支。

QA 主干可以分支进行单元测试，同时维护主干进行集成测试。

生产主干永远不会分支，但会针对每个生产版本进行标记。如果有人必须解决问题，代码将被导出而不是签出。更改将应用​​于开发主干。

• 查看开发代码
• 应用生产修复更改
• 提交开发代码。

您需要一个人和一个流程将代码从开发主干移动到 QA 主干，还需要一个人和一个流程将代码从 QA 主干移动到生产主干。