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

因为我们是在一个部署的系统上开发的，所以我们正试图更好地利用分支——直到最近，几乎所有的东西都只是签入主干，部署到测试/登台，然后是生产。这意味着我们在“测试”期间必须非常小心，而且我们仍然偶尔会在很少测试的情况下将不需要的更改发送到服务器

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

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

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

因此，这两种模式可能导致这样的情况：您希望将一个分支与生产部门合并，以引入一个重要的功能，但该分支已经从您不想发布的主干中“引入”了更改

---

SVN能处理这个吗？对于开发每两周部署一次的代码的团队来说，真的有好的实践吗？

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

描述你的分支（和合并）策略。您无法轻松地混合所有这些策略，而且开发人员很难知道在何处使用了哪种策略，因此文档和通信是关键。请参阅以下参考资料：

您将使用以下选项：

• 发布分支用于生产发布，补丁直接在那里开发。对于每个补丁，您必须决定该补丁是否在下一版本中可用（以相同的形式）
• 使用主干进行主开发。您确信下一版本中的所有内容都应该在主干上开发。不要从主干合并到（释放）分支。永远不会
• 仅当您不确定某个功能是否将进入下一版本时，才使用功能分支。功能分支（在Subversion中）比Git中要困难得多，所以应该有理由使用它们。定期合并从主干到功能分支的所有更改，并且仅在功能集成到主干时（以使其进入下一版本）在末尾重新集成

找到执行分支和合并的正确时间点：

• 分支：什么时候需要一个稳定的发行版分支（为了集成到下一个发行版），什么时候可以开始下一个发行版的开发（然后再次在主干上）
• 合并：何时是合并更改的最佳时间：立即，当更改是新的；不时定期；（希望不是）最后只有一次

随着时间的推移，您的分支将发展如下：

对于第一个版本1.0，您从主干开始（并且只有主干）

当您想对1.0版进行集成测试时，可以对主干进行分支，并开始1.1版的开发（在主干上）

您可以交付1.0版，并直接从分支提供后续补丁

当您想对1.1版进行集成测试时，可以对主干进行分支，并在主干上开始1.2版（或2.0版）的开发

。。。等等

---

SVN的红皮书解释了您在技术上需要的一切，但不太清楚如何在不同的业务环境中做到这一点（我个人的意见）。我还没有找到足够详细的资源来解释所有选项和它们背后的驱动程序…

是否要将功能合并到生产中，而不将其合并到主干中？使用Subversion 1.8，您的运气会更好。它对合并引擎有一些显著的改进，特别是对于更高级的用例，比如兄弟合并。就我个人而言，我将把trunk视为国王：那里没有开发，只有从trunk之外创建的功能分支进行合并。您对一个特性分支执行常规QA，一旦它被签署，就将其合并回主干。然后，标记行李箱并将其投入生产。新功能分支出主干，循环再次开始。如果有一个bug必须立即修复，则在标记的修订处创建一个bug修复分支，修复bug，进行QA，然后再次将其合并，标记并发布到生产中。一旦您发布了几个版本，就很容易遵循此工作流。就我的两分钱。@Sameer这看起来和“生产”分支使用的流程完全一样，但在另一个地方，我完全不介意，但在什么时候测试功能的集成（不是开发测试，而是允许QA在发布之前测试整个功能集？）我的团队实践敏捷。我们有每天的Scrum，每周的Sprint，两周后我们通常会进行QA，合并后签核并部署到生产中。在第一个星期一的scrum中，团队为本周挑选一些bug和特性，在随后的每个scrum中，团队检查已经取得的进展。两周后（实际上，到第二个星期三），我们有一组完成的任务（修复了bug，增加了功能），可以发送给QA。到周五，我们会得到批准，可以合并并部署到生产环境中。有没有办法处理这样的情况：一个功能签入主干，其他功能分支将这些更改合并起来，然后重新集成到主干中——但是你想在没有第一个功能的情况下发货？我只是在玩SVN，我想我回答了自己的问题--“还原此修订版所做的更改”似乎很好地完成了这项工作。