“后备箱”应该是什么？开发或发布

Question

我有一个不幸的机会通过 Borland 的 StarTeam 进行源代码控制。不幸的是，它几乎没有什么事情做得很好，其中一个最大的弱点是它的视图管理。我喜欢 SVN 并且具有 SVN 心态。我们的问题是后期制作发布，我们花费了无数的时间将更改合并到“生产支持”环境中。

请不要骚扰我，这不是我做的，我继承了它，并试图提出一种更好的管理存储库的方法。无法切换到不同的 SCM 工具。

当前设置

• Product.1.0（TRUNK，当前生产代码，在此级别上有待修复的错误）
  • Product.2.0（真正的主干，所有签入的内容都经过测试，然后发布下一个生产周期，此视图中发生了很多更改）

我的建议是交换它们，让所有开发都在主干上完成（生产），标记版本，并根据需要创建子视图来表示生产支持错误修复。

• 生产
  • 生产.2.0.SP.1

我找不到任何文档来支持上述提案，因此我试图获得有关更改是否是个好主意以及您是否建议采取不同做法的反馈。

Answer 1

我使用受 Henry Kniberg 的文章 多个敏捷团队的版本控制。下面我引用一小部分：

大局

好的，现在我已经完成了一个相当详细的示例来说明如何使用此模式。现在让我们退后一步，看看大局。

在主线模型中，分支称为代码线（实际上，分支被认为是代码线的实现）。有时这些被称为流。

代码线的父级（即它起源的代码线）称为它的基线。主线是没有基线的代码线。

因此，在上面的示例中，我们可以得出结论：

• 主干线是我们的主线。它没有父项吗？
• 所有其他代码线（版本 1.0、团队 A 工作、团队 B 工作）都将主干作为基线。

这是一个更复杂的示例：

_{（来源：infoq.com< /a>)}

这张图告诉我们：

• 项目 X 代码线已生成
  来自主线。该项目现已
  完成，因此分支已关闭。
• A 团队有一个活跃的工作分支
  是从主线衍生出来的。
• A 队也有一个持续的峰值，
  从工作分支中产生。
• 2.3 版本分支已关闭，因为
  2.3 不再生产且不会维护。

每条代码线都有相对的硬度
相对于其基线的水平，
即每个代码线要么更坚定
或不如其坚硬（软）
基线。

• 坚定的代码线是稳定的，
  经过彻底测试，很少改变，并且
  即将发布。
• 软代码线不稳定，几乎没有经过测试，
  经常变化，而且还很远
  发布。

绘制代码线时，确定代码线
向上分支和软代码线
向下分支。所以看着
上图，我们可以得出结论：

• 2.3 版比
  主线。
• A队的工作比较柔和
  比主线。
• A 队扣球是
  比 A 团队的工作更轻松。

总结一下：

• 主干是 DONE 分支（始终可发布）
• 工作在工作分支（每个团队一个）中完成，工作分支可能不如主干稳定
• 发布分支是在发布时基于主干创建的。

我强烈建议您阅读整篇文章。

Answer 2

以下是我对构建构建流的一般建议：

+HEAD - master -> current development 
+ tags
   + version1 
   + version1.sp1 
   + version1.sp2 
   + version2
+ branches
   + version1.sp2.fixes <- at some point, this will get promoted to version1.sp3 
   + version2.fixes <- at some point, this will get promoted to version2.sp1 
   + version2.nix.feature1 <- this is your (nix's) private version2.feature branch 
   + master.nix.feature2  <- this is your (nix's) private new development feature branch.

基本上，您永远不会直接提交到 .fixes 或 master 分支 - 只有集成过程才能做到这一点。

无论如何，几乎所有源代码控制工具都支持这种模型。

Answer 3

我同意你和克里斯·卡明斯基的方法。我们使用 StarTeam，这就是我们的使用方式。每个项目中的提示或主视图是当前开发线（在 StarTeam 术语中，这是与项目名称同名的默认视图）。每当我们在此视图上进行构建时，我们的构建服务器都会创建一个构建标签。发布是从某个构建标签开始完成的。

然后，我们将从该标签创建一个新视图作为生产版本分支，然后对该版本的任何错误修复都将应用于该视图（无论错误修复是在提示视图中完成并合并到分支还是反之亦然） ，只要它们确实合并到主开发视图中）。

此外，如果我们有一个需要长时间运行并且不会在下一个正常生产版本之前完成的特定项目，我们将使用“更改时分支”设置从“提示”视图中创建一个分支。这绝对不太理想，因为完成后必须进行大量合并，但它确实将该代码排除在主开发线之外，并确保它不会意外地最终进入生产版本。我们确实试图限制这些类型的项目，但有时是业务人员决定的。

这种设置对我们来说非常有效，并且对于新手来说似乎很容易理解和使用。