-1

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

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

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

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

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

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

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

正确的方法是什么？

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

谢谢。

4

2 回答 2

1

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

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

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

  • 主干（只有一个）：所有自动测试通过，仅包含已完成的功能和错误修复
  • 功能分支（通常是多个）：专用于单个功能或错误修复，通常构建，自动测试通常通过，完成后重新集成到主干并删除
  • Stabilization branch (may be multiple, but usually one): dedicated to a planned release, automatic tests pass, used to generate builds to be sent to QA, internal/external release tags are created from it, some fixes or even features may be merged here from the trunk
于 2013-02-12T20:24:58.640 回答
-1

正确的方法是什么？

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

仅当您要分叉项目时，才需要开发分支。

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

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

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

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

于 2013-02-12T19:34:02.257 回答