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 回答