1

我们的分布式团队（3 个内部开发人员和 3 个以上外部开发人员）使用 SVN 来管理我们的网站代码库。我们为每个次要版本（4.1.0、4.1.1、4.1.2 等）都有一个分支。我们有一个主干，当我们发布并发布到我们的站点时，我们会将每个版本合并到其中。

因此，我们遇到的问题的一个示例是：添加了一个新功能，我们将其称为 4.1.1 的“创建项目的能力”。依赖于 4.1.1 中的功能的另一个功能计划在 4.1.2 中使用，称为“向项目添加任务的能力”。

因此，在星期一，我们说 4.1.1 已“关闭”，需要进行测试。我们的远程开发人员通常会在此时开始研究 4.1.2 的功能/票证。在这一周内，我们将测试 4.1.1 并修复所有错误并将它们提交回 4.1.1。然后，在周五左右，我们将标记 4.1.1，将其与主干合并，最后将其与 4.1.2 合并。但是，在我们测试的 4-5 天里，4.1.2 中没有 4.1.2 的某些新功能所依赖的 4.1.1 代码。

因此，添加“向项目添加任务的能力”功能的开发人员没有“创建项目的能力”功能可以构建，并且必须做一些文件复制恶作剧才能继续工作.

我们可以/应该做些什么来平滑这个过程？

PS 抱歉，如果之前有人问过这个问题 - 我确实搜索过，但找不到我要找的东西。

4

5 回答 5

2

听起来你需要一个基于主干的分支 X，以及一个基于 X 的分支 Y。

您可以在 X 中开发一个功能，并开始对其进行测试。同时，您将 X 复制到新的分支 Y，并在那里开发第二个功能。

最终 X 被合并到主干并被释放。然后当你完成 Y 的工作后，你可以将它合并回 X 进行测试，然后合并到主干中进行发布。

您可以在两个功能都发布后重复此过程。下次你在 X 中完成一个特性，并想在它的基础上进行构建，只需将它合并回 Y。

如果您这样做，请务必记住：

  • 您可以从主干正常合并到 X，然后从 X 合并到 Y。
  • 您确实将合并从 X 重新整合回主干，并从 Y 重新整合回 X。
  • 重新集成合并到主干后，您需要阻止提交合并回 X。
  • 在重新集成合并到 X 后，您需要阻止提交合并回 Y。
  • 详细记录哪个功能在哪个分支中；否则这会很快变得混乱。
于 2010-05-13T00:47:13.703 回答
1

我们这样做的方式是所有开发都发生在主干中。您甚至只提交到主干，然后将 4.1.1 所需的任何修复从主干合并到4.1.1 分支。4.1.2 的分支仅在 4.1.2 开始测试时创建 - 一旦创建 4.1.2 分支，主干中的工作将继续，如果 4.1.2 需要任何修复，它们将在主干中进行，然后合并到4.1.2.

我们很少对需要合并回主干（或其他任何地方，真的）的分支进行更改。

于 2010-05-13T00:38:11.107 回答
1

除非有理由将它们放在其他地方，否则我会将所有新提交放入主干。例如，通过为 4.1.1 和 4.1.2 创建不同的分支，您的示例最好通过在分支之间进行合并来处理，然后这两个分支都可以合并回主干。呸！在我看来，这就是mergeinfo 地狱。

以下是 Subversion 书中的一些基本建议：

http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html

于 2010-05-13T00:42:14.293 回答
0

我想有几种方法可以做到这一点。

但我练习树干总是稳定的。没有未完成的 - 不稳定的代码应该进入主干。如果要添加一个新功能并且需要几天甚至几周的时间，那么我会为它创建一个分支。完成后，分支看起来稳定且经过测试，它再次合并到主干中，分支被删除。

这样后备箱就会保持稳定。实验代码始终是我的分支。

如果我出于某种原因改变主意并跳过一个完成了一半的项目，我不必考虑后备箱。我只是删除分支....

于 2010-05-13T00:45:51.067 回答
0

一种方法是从 4.​​1.1 分支 4.1.2，而不是从主干（当然还有 4.1.1 从主干）。

然后，您可以轻松地将 4.1.1 定期合并到 4.1.2 中，并且仍然能够在发布时为每个分支执行简单的合并回主干。

于 2010-05-13T00:45:52.300 回答