每一点变化的分支？

Question

我们有一个客户（拥有一个客户端，有一个客户端）让我们对代码库的变更请求感到厌烦（在PHP中）。我们的第一个响应是在SVN的主干中工作，但客户端经常回来并请求某个更改需要尽快推送到实时服务器。另一方面，其他变化的优先级突然降低，最初与其他变化（看似）有关。

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

谢谢！

修改：选择正确答案是一个非常难的问题。感谢大家的回答。

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

编辑：现在已经差不多一个月了，我的同事/客户已经说服了我，多个分支机构是要走的路。这不仅仅是因为客户的精神错乱，而且还基于我们需要能够确定某个功能是“准备就绪”还是“需要更多工作”等等。我没有SVN，但我们使用SVN Cookbook的建议进行合并：将从分支合并到分支的修订版本。

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

上次修改（或许）：几个月后，这个系统仍在为我们服务。我们为每张票创建分支，很少遇到问题。另一方面，我们确实试图将人们的工作分开......

两年后：我们现在使用GIT，现在这个系统实际上非常合理。

Answer 1

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

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

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

Answer 2

如何为客户的实时版本创建分支，为新开发创建分支，为正在进行的更改创建分支。

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

当你正在修复他们一直让你疯狂的所有有趣的东西时，在正在进行的变更分支中工作。修复后，将其合并到“实时”分支和“新开发”分支。

通过这种方式，您的客户的分布在他们自己的世界中，您的新开发将继续（并且可以在您需要时合并）并且还可以捕获您的维护。

我们在一个新的开发分支工作，然后每次我们决定制作补丁时，我们分支主干，然后关闭Q / A发送补丁。如果它来回走了一段时间，我们在该分支中工作以修复那些合并回主干的问题，以确保一切都是同步的。如果在之前版本需要解决的事实之后很久就会出现问题，我们可以随时将其修复回该分支，然后再将其合并到主干中。

Answer 3

线程开启者解释的场景是特征分支模式的一个示例：http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html#svn.branchmerge.commonpatterns.feature

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

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

Answer 4

每个变更请求的分支听起来都有点矫枉过正，以后可能会有些麻烦。

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

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

Answer 5

每个更改请求的分支，以及相应的额外管理客户端成本的增加，是解决此问题的一种很好的方法。

在时间，可用于处理其他功能的资源等方面，您将花费更多，但是由于许多不相关的更改或项目功能停滞或取消，它可能是更好的方法之一

这实际上是SCM系统不可知的 - 但是Subversion当然可以做所需的事情。

Answer 6

根据测试，工作更改分支 每个版本的标签。
在后备箱中发展。
重复。

：）

Answer 7

每个RELEASE都有一个分支。将尽可能多的更改组合到一个版本中是有意义的 - 有更多的分支通常是好的，你可以在大多数情况下轻松地将它们组合，将它们分开是有点棘手。

每个版本都有一个分支意味着您还有一个分支用于当前正在生产的内容（或者在合并后但在实际部署之前版本待处理时才会发布的内容）。

这就是我们所做的。

Answer 8

在我的工作场所，我们有以下系统：

• 稳定分支：这是经过测试和验证的稳定代码。
• 维护分支：这是修复稳定错误的地方。当事情被证实有效时，它会合并到稳定的分支。
• 项目特定分支机构：我们产品中的每个子项目都有一个分支机构。在一年中的特定时间，将包含在今年发布中的所有项目合并到“发布分支”中。这是所有合并和东西都没有在发布前一周完成。
• 发布分支：这是在子项目合并之后发生当前版本的所有混乱开发的地方。完成后稳定合并。

Answer 9

使用git，我做为每一个小变化做一个分支，我喜欢它！

Answer 10

在项目的“实时”分支中进行大量快速更改时，您需要进行可靠的代码审查流程，以减少破坏它的可能性。必须在办理登机手续之前完成代码审查;并远离那个分支的核心发展。

批准更改后，您可以签入更改（和/或从工作分支合并）并在完成后创建新的“标记”。

Answer 11

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