Svn Subversion分支和发布计划

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

开发人员将更改提交到subversion存储库

构建对QA服务器的更改

生成对生产服务器的更改 问题是我们在SVN主干中使用一个源代码集来完成所有这些步骤

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

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

我想使用subversion分支可以克服这个问题。希望我可以为QA/live server版本创建一个单独的分支，并且可以合并来自head/trunk的必要更改

还是反过来？为QA/live server版本保留head/trunk版本，并为开发提交创建分支

正确的方法是什么

请告诉我是否有更好的方法/工具来处理这种情况

谢谢

正确的方法是什么

这是一个观点，但创造3个树干。一个用于开发，一个用于QA，一个用于生产

只有当你在分岔项目时，开发分支才是必要的

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

生产主干永远不会分支，但会为每个生产版本添加标签。如果有人必须修复问题，代码将被导出而不是签出。这些变化将应用于开发主干

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

---

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

SVN中有一种非常流行的分支方法。这里描述的是：

在我的项目（一个人的项目，有一个单独的发布周期）中，我使用了发布和特性分支，没有任何问题

具体的分支机构政策可能会有所不同，以下是适合我的：

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

---

按照惯例，如果只有一个中继，您可能会得到更好的答案。其余的只是树枝。谈论开发主干和qa主干是令人困惑的。@thekbb：您可以设置任意多个Subversion目录。每个目录至少有一个主干。我有一个Subversion目录，有20个中继，用于20个不同的项目/当然。您可以根据需要创建名为“任意”的目录。没有规则。。。但是有一些惯例。红皮书中描述的标准分支、标签和主干很容易被您使用的任何工具接受。这样别人就会知道你在说什么。