想要改进这个问题吗？ 更新问题，以便 editing this post 提供事实和引用来回答它.
关闭 2 个月前。
我们已转向产品版本控制方法，该方法将根据以下格式标记/增加构建:[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虽然对并发分支的独特版本控制有点模糊。
最佳答案
经过近两周的思考、来自 StackOverflow 和我认为是变革管理领域专家的业内人士的对话和反馈，我们昨天达成了共识。
确实没有正确或错误的答案 - 没有 Elixir - 正确处理分支/合并，恕我直言，它因企业和产品而异。这就是我们决定继续前进的方式:
不管主干还是分支，我们将继续按照 [Major].[Minor].[Build].[Rebuild] 的格式进行编号，其中 rebuilt 表示构建版本。分支和主干将不同步(不同的内部版本号)，但这不是问题，因为我们将明确定义我们的构建配置和删除位置。了解哪个版本部署到哪个服务器将是环境管理责任。
我们可能不会将功能合并到发布分支中，因为我们通常更关注发布分支，因此我们将从候选分支发布并在合并之前增加主干(以及其他分支，如果适用)上的次要版本部署发布后(如果适用)一直到主干。
由于每个版本都会引发次要版本增量(补丁除外)，因此构建编号永远不会倒转。补丁显然来自 prod 分支，因此内部版本号会增加。
我打算让这个帖子保持开放状态，让其他人写下他们首选的管理分支版本控制的技术。
https://stackoverflow.com/questions/7155135/