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

Question

由于我们正在开发已部署的系统，我们正在努力更好地利用分支 - 直到最近，几乎所有东西都只是检查到主干，部署到测试/暂存然后生产。这意味着我们必须在“测试”期间非常小心，并且我们偶尔会在很少测试的情况下将不需要的更改发送到服务器。

我的想法是，最好的方法是“小”补丁直接进入主干，主要功能成为功能分支，在完成时重新加入主干，以及"Production" branch总是匹配我们可以的服务器状态在部署之前合并。

这里提供的主要好处是，您可以选择要进行生产的更改 - 如果您愿意，您可以抓住一个签入或分支并将其发送到生产而不涉及所有其他分支。

另一方面，似乎最好让分支经常与主干集成 - 拉起变化，这样它们就不会累积并产生令人讨厌的合并。

因此，这两种模式可能会导致您希望将某个分支与Production合并以带来一个重要的功能，但该分支已经从您不想发送的主干中“拉入”更改。

SVN可以处理吗？是否真的有良好的做法适用于开发每两周部署一次的代码的小组？

Answer 1

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

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

您的分支机构将随着时间的推移而发展：

1. 首先发布1.0版本的主干（并且只有主干），第一个版本。
2. 如果要对1.0版本进行集成测试，并在1.1版本（在主干上）开始开发，则分支主干。
3. 您提供1.0版本，并直接从分支机构提供补丁。
4. 如果要对1.1版进行集成测试，请在主干上进行分支，然后在主干上开始发布1.2版（或2.0版）。
5. ......依旧......
SVN红皮书的Branching and Merging解释了您在技术上需要的一切，但不清楚如何在不同的商业环境中做到这一点（我的个人观点）。我没有找到足够详细解释其背后的所有选项和驱动程序的资源......