SVN 分支/合并功能分支和生产分支

Question

由于我们是在已部署的系统上进行开发，因此我们正在尝试更好地利用分支——直到最近，几乎所有东西都被检入到主干中，部署到测试/登台然后生产。这意味着我们在“测试”期间必须非常小心，我们仍然偶尔会在几乎没有测试的情况下将不需要的更改发送到服务器。

我的想法是，最好的方法是“次要”补丁直接进入主干，主要功能成为功能分支，在完成后重新集成到主干，"Production" branch 始终与我们可以合并的服务器状态匹配就在部署之前。

这里提供的主要好处是，您可以选择将哪些更改推出到生产环境中——如果您愿意，您可以获取单个签入或分支并将其发送到生产环境，而无需涉及所有其他分支。

另一方面，最好让分支经常与主干集成——拉起更改，这样它们就不会累积并进行令人讨厌的合并。

因此，这两种模式可能会导致您希望将分支与生产合并以引入重要功能，但该分支已经从主干“拉入”了您不想发布的更改。

SVN 可以处理这个吗？对于每两周部署一次的代码开发团队来说，真的有很好的做法吗？

Answer 1

我认为您所描述的所有内容都可以使用（当前版本，如 1.7 或 1.8 的）Subversion。以下是要采取的步骤：

1. 描述您的分支（和合并）策略。你不能轻易地将它们混合在一起，开发人员也很难知道在哪里使用了哪种策略，因此文档和沟通是这里的关键。请参阅以下资源：
   • Best branching strategy when doing continuous integration?
   • Common Branching Patterns
2. 您将使用以下内容：
   • 生产版本的发布分支，补丁直接在那里开发。对于每个补丁，您必须决定该补丁是否应该在下一个版本中可用（以相同的形式）。
   • 使用主干进行主要开发。您确定将在下一个版本中发布的所有内容都应该在主干上开发。不要从主干合并到（发布）分支。永远不会！！
   • 仅当您不确定某个功能是否会进入下一个版本时才使用功能分支。功能分支（在 Subversion 中）比例如在 Git 中，所以应该有理由使用它们。定期将所有更改从主干合并到功能分支，并仅在最后将功能集成到主干时重新集成（以使其进入下一个版本）。
3. 找到执行分支和合并的正确时间点：
   • 分支：何时需要稳定发布分支（以集成到下一个版本），何时可以开始下一个版本的开发（然后再次在主干上）？
   • 合并：何时是合并更改的最佳时间：立即，当更改新鲜时；不时定期； （希望不会）最后只有一次。

随着时间的推移，您的分支将像这样开发：

1. 您从第一个版本 1.0 的主干（并且只有主干）开始。
2. 当您想要对 1.0 版进行集成测试时，您可以对主干进行分支，然后开始为 1.1 版（在主干上）进行开发。
3. 您交付 1.0 版，然后直接从分支提供补丁。
4. 当您想要对 1.1 版进行集成测试时，您可以对主干进行分支，然后在主干上开始开发 1.2（或 2.0）版。
5. ...等等...

Branching and Merging 的 SVN 红皮书解释了您在技术上需要的一切，但不太清楚如何在不同的业务环境中做到这一点（我个人的看法）。我没有找到足够详细地解释所有选项和驱动程序的资源...