build - 什么是有用的分支版本控制策略？

Question

关闭。这个问题是 opinion-based .它目前不接受答案。

---

想要改进这个问题吗？ 更新问题，以便 editing this post 提供事实和引用来回答它.

关闭 2 个月前。

Improve this 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 和我认为是变革管理领域专家的业内人士的对话和反馈，我们昨天达成了共识。

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

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

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

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

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