使用功能分支和生产分支进行 SVN 分支/合并

Question

使用功能分支和生产分支进行 SVN 分支/合并

svnbranching-and-merging

3

由于我们正在开发一个已部署系统，因此我们正在尝试更好地利用分支——直到最近，几乎所有内容都被检入主干，然后部署到测试/暂存和生产环境。这意味着我们必须在“测试”期间非常小心，仍然会偶尔出现未经充分测试就发送到服务器的不必要更改。

我的想法是，“小”的修补程序直接进入主干，重要功能成为特性分支，在完成后重新集成到主干，并且有一个{{link1：“生产”分支}}，始终与服务器状态匹配，我们可以在部署之前合并到该分支。

这里提供的主要优点是，您可以选择要滚动到生产环境的更改-如果您喜欢，您可以获取单个签入或分支并将其发送到生产环境，而不涉及所有其他分支。

另一方面，似乎最好经常将分支与主干集成-拉取更改，以便它们不会累积并进行恶劣的合并。

因此，这两种模式可能导致这样一种情况，即您希望将分支与生产环境合并，以带来一个重要功能，但该分支已经从您不想要的主干中“拉入”了更改。

SVN能够处理这个吗？有没有真正有效的做法适用于每隔几周部署代码的团队开发？

- Bill K

你想将功能合并到生产环境而不将其合并到主干吗？ - maxim1000

你使用Subversion 1.8会更加幸运。它对合并引擎进行了一些显著的改进，特别是针对较为复杂的使用场景，如同级合并。 - randy-wandisco

1

个人而言，我会把主干视为王者：在那里不进行开发，只有从主干创建的特性分支合并。您可以在特性分支上进行常规QA，一旦签署完毕，将其合并回主干。然后，标记主干并将其推送到生产环境。从主干创建新的特性分支，然后循环开始。如果必须立即修复错误，则从已标记的版本中的主干创建一个错误修复分支，修复错误，进行QA，然后再次合并，标记并发布到生产环境。一旦您发布了几个版本，遵循此工作流程就非常容易了。这只是我的个人意见。 - Sameer Singh

@Sameer 这似乎与“Production”分支使用的过程完全相同，只是在不同的地方，我完全接受，但是你何时测试功能集成（不是开发测试，而是允许QA在发货之前测试整个功能集？） - Bill K

我的团队实践敏捷开发。我们每天进行站会，每周进行冲刺，两周后通常进行QA测试，合并通过签署的代码并部署到生产环境。在第一个星期一的站会上，团队会挑选本周需要解决的一些问题和功能，在每个随后的站会上，团队会检查已经完成的进度。两周后（实际上是第二个星期三），我们有了一组已完成的任务（修复的问题，添加的功能），可以发送给QA进行测试。到星期五，我们获得了签署，并可以合并和部署到生产环境。 - Sameer Singh

我们还使用语义化版本控制，以便我们的构建和发布具有如下形式的版本号： 主版本号.次版本号.修订号.版本号。希望这有所帮助。 - Sameer Singh

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- mliebelt · Accepted Answer

我认为你所描述的一切都可以通过Subversion（例如1.7或1.8的当前版本）实现。以下是需要采取的步骤：

描述你的分支（和合并）策略。你不能轻易地混合所有这些策略，而且开发人员很难知道在哪里使用哪种策略，因此文档和沟通至关重要。请参阅以下资源：

你将使用以下策略：

发布分支用于生产发布，补丁直接在该分支上开发。对于每个补丁，你必须决定是否应该在下一个发布中以相同的形式提供。
使用主干进行主要开发。所有确定会在下一个版本中的内容都应该在主干上开发。不要从主干向（发布）分支合并。千万不要！
只有当你不确定某个功能是否会出现在下一个版本中时，才使用功能分支。在 Subversion 中，功能分支比 Git 等工具更加困难，因此必须有理由使用它们。定期将主干上的所有更改合并到功能分支中，并仅在最后重新整合，当该功能集成到主干中时（以便进入下一个版本）。

找到适合进行分支和合并的时间点：

分支：何时需要稳定的发布分支（用于集成到下一个版本中），何时可以开始为下一个版本进行开发（然后再回到主干上）？
合并：何时是合并更改的最佳时间：立即，在更改刚出现时；定期从时间到时间合并；（希望不要）仅在最后一次合并。

你的分支将会像这样随着时间发展：

1. 你从主干开始，对于第一个版本（1.0版），只有主干存在。 2. 当你想要进行第一个版本（1.0版）的集成测试并开始开发第二个版本（1.1版）时，你会从主干创建分支。 3. 你发布第一个版本（1.0版），之后直接从分支提供补丁。 4. 当你想要进行第二个版本（1.1版）的集成测试并开始开发第三个版本（1.2版或2.0版）时，你会从主干再次创建分支。 5. ...等等...

SVN红皮书中的分支和合并解释了所有技术细节，但在不同的业务背景下如何操作并不是很清晰（这是我的个人观点）。我还没有找到一份资源可以详细解释所有选项及其背后的驱动因素。