什么应该是“主干”开发或发布

Question

我有幸通过Borland的StarTeam进行源代码控制。不幸的是，它做得很少，而且它的观点管理是一个至高无上的弱点。我喜欢SVN并且来自SVN心态。我们的问题是后期制作发布，我们花费了无数个小时将变更合并到“生产支持”环境中。

请不要骚扰我这不是我的行为，我继承了它，并试图提出一种更好的管理存储库的方法。切换到其他SCM工具不是一个选项。

当前设置

• Product.1.0（TRUNK，当前生产代码，此级别正在等待修复错误）
  • Product.2.0（真正的中继任何已检入的内容都经过测试，然后在下一个生产周期中发布，此视图中会发生很多变化）

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

• 生产
  • Production.2.0.SP.1

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

Answer 1

我使用了Henry Kniberg的文章Version Control for Multiple Agile Teams启发的中间方法。我在下面引用一小部分：

  

大图

     

好的，现在我已经详细介绍了如何使用这个模式。现在让我们退一步看看全局。

     

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

     

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

     

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

     

  
• 行李箱是我们的主线。它没有父母的权利吗？
  
• 所有其他代码行（1.0版，团队A工作，团队B工作）都将主干作为基线。
  

     

这是一个更复杂的例子：

     

     

这张照片告诉我们：

     

  
• 项目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或主分支 - 只有集成过程才能这样做。

无论如何，几乎任何源代码控制工具都会支持这个模型。

Answer 3

我同意你和Chris Kaminski的做法。我们使用StarTeam，这就是我们使用它的方式。每个项目中的提示或主视图是当前的开发行（在StarTeam术语中，这是与项目名称同名的默认视图）。每当我们构建此视图时，我们的构建服务器都会创建一个构建标签。从某个构建标签开始发布。

然后我们将创建一个新的View作为该Label的生产版本分支，然后将该版本的任何错误修复应用于该视图（错误修复是否在Tip视图中完成并合并到分支或副）反之亦然，只要它们合并到主要的开发视图中。）

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

这个设置对我们来说非常有效，似乎很容易让新人理解和使用。