Question

我们已经转向产品版本控制方法，该方法将根据以下格式标记/增加构建：[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，尽管在并发分支的唯一版本化方面有点模糊。

Answer 1

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

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

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

我们可能不会将功能合并到发布分支中，因为我们通常会有更多的发布分支焦点，所以我们将从候选分支中释放并在合并之前在主干（以及其他分支，如果适用）上增加次要版本部署发布后（如果适用），直至主干。

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

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

Answer 2

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

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

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

Answer 3

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

对于每个新的x.y版本，我宁愿有一个专门的合并分支，我可以合并为下一个版本选择的所有功能分支（因为某些功能可能没有及时准备好），以及x.y部分是有意义的。

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