DVCS - 标记多个修订答案

【问题标题】：DVCS - tag multiple revisionsDVCS - 标记多个修订
【发布时间】：2013-09-05 11:35:24
【问题描述】：

我想到了这样的发布工作流程：
- 一个分支是 trunk 分支 - 它可能具有用于功能和其他目的的子分支。
- 第二个分支是 stable - 它代表生产版本。
- trunk 的修订版 - 标记为发布版本。如果我想发布 - 我必须为发布版本指定一个或多个变更集，然后将它们合并到 stable，并且此多重合并的最终最终修订版将是一个新的 stable 版本。

有一个选项 - 使用一些外部工具来跟踪版本修订属于哪个版本，或者将此信息写入提交消息中 - 但我不喜欢它们，因为我想将此信息存储在 DVCS 中，而不是依赖任何外部软件进行发布管理。

所以我的问题是：
- 这是一个好的方案吗？
- 任何流行的 DVSC 是否有这样的工具，用于批量标记修订？

【问题讨论】：

“批量标记”？您的意思是要标记作为版本一部分的所有修订吗？这不是 Git 做标签的方式。它们旨在标记一个版本，该版本代表该版本之前的所有历史记录。此外，您描述的工作流程听起来类似于this one。

标签： git version-control mercurial merge dvcs

【解决方案1】：

这是一个好的方案吗？

没有。在无用的实体中单独的“稳定”分支仅带来额外的头痛（至少在 Mercurial 和 Git 中），在“主干”内标记将起作用

对于任何流行的 DVCS 是否有这样的工具，用于批量标记修订？

不（至少我不知道这样的工具）。但是（对于 Mercurial，f.e）根本不需要它：通过一些 revset 的魔法，您总是可以“跟踪 repo/ 修订中属于哪个版本 /tag”

【讨论】：

不同意无用的stable - 如果生产需要从trunk（代表开发过程的历史）中获取一些非顺序的非历史变更集怎么办？因此，我需要将它们合并到 trunk 中并进行新的提交，这很可能与当前的开发状态无关，而当前的开发状态已经可能脱离发布所代表的状态。
@GillBates - 您对 PROD 的要求非常奇特，与现实生活无关，但是无论如何 - 在 开发分支问题不大

【解决方案2】：

这在 Mercurial 中相对容易做到，您可以为一个命名分支设置多个头，但是在 git 或 mercurial 中，您最好使用一个名为“release_candidate”的分支，将任何功能合并到其中您认为是发布候选的分支。然后 TPTB 将 'release_candidate' 合并到 'stable' 或不合并，如果他们不合并，您只需使用被拒绝候选的可接受子集创建一个新的候选发布 - 您始终可以创建一个新分支并仅合并您的想进去。

【讨论】：