18

我们有一个客户(谁有一个客户,谁有一个客户),他对代码库(在 PHP 中)的更改请求让我们发疯。我们的第一反应是只在 SVN 的主干中工作,但客户端经常回来并请求需要尽快将某些更改推送到实时服务器。另一方面,其他更改的优先级突然降低,最初是与其他更改组合在一起的(似乎)。

我们正在考虑为每个变更请求使用一个分支。这是疯了吗?还有哪些其他解决方案可能有效?

谢谢!

编辑:这是一个很难选择正确答案的问题。感谢大家的精彩回答。

编辑:我知道我选择的最佳答案并不是特别受欢迎。我也想找到解决这个问题的技术方案。但是现在我认为如果客户想要的软件具有可以以模块化方式部署的功能......这个问题应该在我们使用版本控制系统时解决。它必须被设计到软件中。

编辑:现在差不多一个月过去了,我的同事/客户已经说服我,多个分支机构是要走的路。这不仅是由于客户的精神错乱,而且还基于我们需要能够确定某个功能是否“准备就绪”或“需要更多工作”或其他什么。我没有 SVN,但我们使用 SVN Cookbook 中的建议进行合并:您将分支它分支的修订版合并到头修订版。

此外,使用这个系统,我们在某个时候合并所有分支,这成为新的 QA,然后是实时构建。然后我们从那里分支。

最后编辑(也许):几个月后,这个系统仍在为我们工作。我们为每张工单创建分支,很少出现问题。另一方面,我们确实尝试将事情分开,就人们的工作而言......

两年后:我们现在使用GIT,现在这个系统实际上是相当合理的。

4

11 回答 11

19

也许这里的 Subversion 并不是完成这项工作的最佳工具。尽管在 SVN 中创建所有这些分支很便宜,但重新合并它们可能会变得耗时且痛苦。

如果你看一下 GIT 而不是 SVN,你会发现一个版本控制系统,它通常在合并方面更强大。除此之外,它还具有“樱桃采摘”的特殊功能。也就是说,可以轻松地从一个开发树中“挑选”单个提交并将其添加到另一个(实时分支)。此外,在 GIT 中将多个提交合并为一个非常方便(您甚至可以从另一棵树添加到特定提交)。

因此,构建单一功能提交然后挑选它们可能是您的解决方案。

于 2008-11-17T17:16:15.847 回答
10

为您的客户的实时版本创建一个分支,为您的新开发创建一个分支,为您正在进行的更改创建一个分支怎么样。

当您没有被任务淹没时,在新的开发分支中工作。

当您修复所有让您发疯的有趣内容时,请在正在进行的更改分支中工作。当你得到修复后,将它合并到“live”分支和“new development”分支。

这样,您的客户的分布就在它自己的世界中,您的新开发继续进行(并且可以在您需要时合并)并且您的维护也被捕获。

我们在一个新的开发分支中工作,然后每次我们决定制作补丁时,我们都会分支主干,然后将该补丁发送出去进行问答。如果它来回一段时间,我们会在该分支中工作以解决这些问题,并在必要时合并回主干,以确保一切同步。如果某些事情在需要在以前的版本中解决的事实很久之后又回来了,我们总是可以在那个分支中修复它,然后再次将它合并到主干中。

于 2008-11-17T17:11:36.557 回答
6

线程开启器解释的场景是功能分支模式的示例: http: //svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html#svn.branchmerge.commonpatterns.feature

当您必须保持主开发线(主干)稳定并且您必须开发许多可能会破坏主线的功能时,它们非常有用。

缺点是您必须使各个分支与主干保持同步:当功能 A 的分支正在开发中时,功能 B 的分支可能已经达到稳定状态并被关闭并合并到主干中:在这种情况下,您必须将B分支引入的更改从主干合并到A分支。因此,经常将分支与主干合并是一个好习惯,以避免在分支生命结束时出现独特的大合并的问题情况,并且有很多冲突需要追踪和解决。

于 2008-11-17T17:57:44.000 回答
3

每个更改请求的分支听起来有点矫枉过正,以后可能会遇到麻烦。

尝试将更改请求分组到逻辑区域,以便您可以看到一组特定的更改对应用程序具有逻辑相关的影响。为这些创建分支。

我认为这个问题的真正答案是修复客户端。您需要通过合同明确这些任意更改请求将花费他们的钱,并且可能会减慢他们的速度。如果这种情况持续下去,您的 svn 存储库将是项目中最不麻烦的方面。

于 2008-11-17T17:13:04.213 回答
3

每个变更请求的分支,以及相应增加客户额外管理的成本,是解决这个问题的好方法。

就时间、可用于处理其他功能的资源等而言,这将花费您更多的成本,但是由于有很多不相关的更改,或者项目功能停滞或取消,这可能是更好的方法之一。

这确实与 SCM 系统无关——但 Subversion 肯定可以做需要的事情。

于 2008-11-17T17:15:22.993 回答
2

每个测试的分支,工作变化。
每个版本发布的标签。
在主干中开发。
重复。

:)

于 2008-11-17T17:17:10.807 回答
2

每个版本都有一个分支。将尽可能多的更改组合到一个版本中 - 拥有更多分支通常是好的,在大多数情况下您可以轻松地将它们组合起来,将它们分开则有点棘手。

每个版本都有一个分支意味着你也有一个当前生产的分支(或者当版本在合并之后但实际部署之前待发布时,即将发布的内容)。

无论如何,这就是我们所做的。

于 2008-11-17T17:57:40.817 回答
1

在我的工作场所,我们有以下系统:

  • 稳定分支:这是经过测试和验证的稳定代码所在的位置。
  • 维护分支:这是在 stable 中修复 bug 的地方。当事情被验证工作时,它被合并到稳定的分支。
  • 项目特定分支:我们产品中的每个子项目都有一个分支。在一年中的特定时间,所有要包含在今年发布中的项目都合并到“发布分支”中。这样所有的合并和东西都没有在发布前一周完成。
  • 发布分支:这是子项目合并后当前发布的所有混乱开发发生的地方。发布完成后与 stable 合并。
于 2008-11-17T17:41:06.950 回答
1

使用 git,我确实为每一个小改动创建了一个分支,我喜欢它!

于 2009-05-09T14:47:18.497 回答
0

在项目的“实时”分支中进行大量快速更改时,您需要有一个可靠的代码审查流程来减少破坏它的机会。代码审查必须在签入之前完成;并远离该分支的核心开发。

一旦更改被批准,您可以签入更改(和/或从您的工作分支合并)并在完成后创建一个新的“标签”。

于 2008-11-17T17:22:51.853 回答
0

当估计的小时数超过 8 时,请使用分支。

于 2009-01-10T12:52:20.793 回答