3

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

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

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

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

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

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

4

1 回答 1

2

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

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

您的分支将随着时间的推移而开发，如下所示：

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

SVN 红皮书的分支和合并解释了您在技术上需要的一切，但不太清楚如何在不同的业务环境中进行（我个人的看法）。我没有找到足够详细地解释它们背后的所有选项和驱动程序的资源......

于 2013-09-07T09:30:18.733 回答