什么是有用的分支版本控制策略？答案

【问题标题】：What is a useful Branch Versioning Strategy?什么是有用的分支版本控制策略？
【发布时间】：2011-11-01 13:53:16
【问题描述】：

我们已转向产品版本控制方法，该方法将根据以下格式标记/递增构建：[Major].[Minor].[Build].[Revision/Patch]，并且生产版本本质上将是主要或次要的增量（取决于更改范围）。

这对于补丁和 Trunk 构建非常有用，但对于分支中的并发功能开发来说不是很好 - 特别是因为我们很可能会在分支之外构建候选发布版本，而不是合并到 Trunk 并发布（不是我的首选选项，但不幸的是，可能更现实）。

无论我们是否合并到主干（或不合并），是否有人有任何有用的策略来处理分支版本控制？我们需要能够从分支和主干中唯一识别构建，并且最终可能会在任何给定时间从主干或分支中发布。

一些注意事项：

（轻量级）方案可能会有所帮助：

Product X\Trunk (ver 1.1.208.0)
Product X\Branches\Feature A (ver 1.1.239.0)
Product X\Branches\Feature B (ver 1.1.221.0)

编辑：迄今为止我发现的最好的文档位于MSDN，尽管它对并发分支的唯一版本控制有点模糊。

【问题讨论】：

【解决方案1】：

我不会将版本号绑定到功能分支，因为在并发开发场景中，您可能需要考虑：

对于每个新的x.y 版本，我宁愿有一个专门的分支用于合并，我可以在其中合并为下一个版本选择的所有功能分支（因为某些功能可能无法及时准备好），以及@987654322 @part 会很有意义。

换句话说，我会将功能开发周期与发布周期分开。

【讨论】：

与上面的注释相同 - 如果您不使用版本号来区分分支的构建，您如何唯一地识别哪个构建来自哪里（分支）......以及何时？
@RobS：集成分支允许您跟踪集成了哪些功能分支，因为您将对所述集成分支进行连续合并。您仍然可以在功能分支上放置构建标签，当所述功能已被选为实际成为下一个版本的一部分时，您将合并到集成分支（这在开始时永远不会自动：功能分支可能运行较晚或过于复杂并推迟到下一个版本）。
嗨 VonC.. 为反馈欢呼。所以当你从你的分支构建时，你在程序集版本控制方面做了什么？标签很好，但是在组装级别上，分支构建部署与主干构建有什么区别？
@RobS：主要是集成分支的命名约定。主分支更多地记录当前生产中的内容（我们再次分支为修复分支）

【解决方案2】：

我们不会为我们的功能分支提供版本号。我们有主开发分支，然后为我们创建的每个特性创建特性分支。当该功能完成，或者完成了不会破坏开发分支的部分功能时，我们合并回开发。

在这样做时，开发分支应该有点稳定。我们每周发布一次，所以每周一我们都会从develop创建一个发布分支，并给出一个版本号。然后测试人员会花一两天时间测试这个分支以确保它稳定，然后我们在周二/周三进行部署。

当我们每周进行部署时，我们不会太担心修复发布分支中的小问题。我们在功能分支中进行，或者如果该分支现在直接在开发中完成。发现的任何重大问题我们都会在发布、部署和合并回开发中修复。

【讨论】：

【解决方案3】：

经过近两周的思考、来自 StackOverflow 和我认为是变革管理领域专家的业内人士的对话和反馈，我们昨天达成了共识。

确实没有正确或错误的答案 - 没有灵丹妙药 - 正确处理分支/合并，恕我直言，它因业务和产品而异。这就是我们决定继续前进的方式：

无论主干还是分支，我们将继续按照 [Major].[Minor].[Build].[Rebuild] 格式进行编号，其中 rebuilt 表示构建版本。分支和主干将不同步（不同的内部版本号），但这不是问题，因为我们将明确定义我们的构建配置和删除位置。了解哪个版本部署到哪个服务器将是环境管理责任。

我们可能不会将功能合并到发布分支中，因为我们通常更关注发布分支，因此我们将从候选分支发布并在合并之前增加主干（和其他分支，如果适用）上的次要版本部署发布后（如果适用）一直到主干。

由于每个版本都会引发次要版本增量（补丁除外），因此构建编号永远不会倒转。补丁显然来自 prod 分支，因此内部版本号会增加。

我打算让这个帖子保持开放状态，让其他人写下他们首选的管理分支版本控制的技术。

【讨论】：