功能、稳定版本等的Mercurial存储库结构

据我所知,您要问的是如何在Mercurial中处理不同的开发分支。在您的示例中,您希望能够轻松地将修复程序发布到发布版本,而不必处理自上次发布以来开发分支中发生的所有事情。

有很多方法可以处理Mercurial中的分支。您可以使用单独的存储库、命名分支和书签扩展。在Mercurial中选择如何处理分支与您拥有的工作流类型有关,但有许多可能的组合。

考虑到这一点,我将对分支之间的工作流给出一些一般性的建议,不管它们是如何在Mercurial中表示的(作为单独的存储库、命名的分支等)。如果您想了解更多关于选择什么分支模型的信息,我建议您阅读 Steve Losh's guide to branching in Mercurial 我的博客帖子在 choosing a branching model in Mercurial .

首先,即使根本没有分支,您仍然可以返回到代码的早期版本,例如2.0版本,并在那里修复这个bug。这将使标记和发布一个新版本(比如2.0.1)变得容易,唯一的更改是修复错误。

您只需更新、修复和提交:

$ hg update 2.0
hack hack hack
$ hg commit -m "Fix nasty bug"
$ hg tag 2.0.1

上面假设您已经标记了2.0修订版,所以很容易找到它,否则您将不得不提供哈希或修订ID。

这会给你两个头,你可以和它合并 hg merge ,将修复程序带回开发版本。

如果您有一个2.0版本的单独存储库,那么您可以在那里进行修复,然后将其拉入开发存储库,然后在其中合并。基本原则是RY4AN概述的一个原则,在没有其他不想要的更改的地方进行更改。

下面是一个例子:

在我工作的地方,我们有许多代表不同分支的存储库。大多数开发发生在“dev”分支中。当一个版本接近时,我们将该存储库克隆到一个新的版本中,称为“release-2.4”。在这个分支/repo中,我们测试并修复即将发布的bug。更多的实验性开发直到下一个版本可以在“dev”中并行发生才准备就绪。

当测试了版本并准备好发布时,我们将所有内容从“release-2.4”拉到“prod”,它只包含已发布的代码版本。我们用一个版本号标记它,然后将它发布到世界上。然后我们可以删除“release-2.4”分支,并将所有内容从“prod”拉到“dev”。这可能需要合并,但随后我们将在发布过程中所做的所有更改放回“dev”中,并可以继续处理下一个版本。

如果我们想在更大的计划版本之外修复一个bug,我们可以用两种方法来解决。如果修复很小(几次提交),或者不涉及很多开发人员,我们可以直接提交到“prod”,标记发布并发布它。之后,我们将从“prod”拉入“dev”,以确保在下一个版本中也有修复。

如果bug修复版本更大并且需要更多的时间,我们可以改为在“prod”上做一个新的分支,在那里完成所有的发布工作,然后将更改拉到“prod”中。当它被释放到“prod”中时,我们就可以从“prod”中“pull”到“dev”中,从而在那里得到更改。然后可以删除特别发布分支。

我希望早点听到的一条建议是“尽早修复bug”,而我不是说在你编写完代码之后就立即修复它。我的意思是,如果您正在修复两年前在变更集编号400中引入的bug,您应该:

hg update 400
vi .... # fix bug
hg commit

mercurial会说“新的头被创建了”,这一点一开始似乎令人震惊,但您所做的是创建一个变更集(实际上是一个匿名分支),可以 hg pull 任何有缺陷的分支。

在我发现这一点之前,我们会在发布分支、开发分支或者其他一些活跃的开发线中修复这个bug,然后我们会想把这个修复转移到其他分支,但做不好。原因是当你拉(分支作为克隆)或合并(命名或匿名分支)时,有一个明确的要求,如果你拉/合并变更集X,那么你拉/合并变更集X的所有祖先——但你不一定要所有这些祖先(可能是w,实验特性)你只需要修复bug。

在没有祖先的情况下移动一个变化,需要通过导入/导出或移植或其他带外机制对另一种形式进行“樱桃采摘”。

但是,如果您使bug fix变更集使它们的唯一祖先是最初创建bug的变更集,那么您可以始终“hg pull”将其修复到具有bug的任何分支中,而不带任何其他东西。

为了让它更多地回到您最初的查询中,如果您使用克隆作为分支(我的首选项)或命名分支,那么上面我建议的内容同样适用。

以下是一个不错的“结构”教程:

http://hginit.com/05.html

我也在熟悉Subversion之后开始使用Mercurial,我对这个开关很满意——hg肯定为我解决了一些问题。我基本上不去管任何一个“指定的分支”,我只是靠头来完成我的工作。我确保充分地使用日志来确定当我需要返回到旧版本时,我需要去哪里。当然,标签也非常好,教程也介绍了这一点。

我为之工作的公司正在娱乐地迁移到Mercurial并考虑支持' 功能分支 '对于正在开发的每个功能。功能分支是一个命名的分支,它包含一些新的开发或者对现有功能的更新——基本上,无论您想要什么。

功能分支只存在于用户的repo克隆中,直到它们准备好集成到开发的主线中,此时它们将被合并回活动的开发分支。如果您有人担任构建管理器角色,那么可以将功能分支推送到未合并的共享回购,并且管理器可以根据需要合并它们。如果不这样做,开发人员可以将它们合并到克隆的repo中,然后推送已经合并的分支。(旁注:hg仍然显示共享回购中合并的功能分支)

一旦共享回购被更新到稳定点,它就可以被标记和发布。错误修复可以应用于标记的版本,如果需要长时间或并行开发,则可以使用标记的版本作为父版本创建第二个活动的开发分支。Ry4an的修正错误的方法也可以在这里应用。

整个工作流可以使用 功能克隆 而不是 功能分支 但它改变了一些发展动态。如果你能给每个人一次发布的尝试,那将帮助你和你的团队做出决定。

编辑以解决新添加的特定问题

假设我明天完成2.0.0…我 想在2.1.0上开始工作,我该怎么做? 怎么办?

在这个方案中,您将在2.0.0完成时制作一个标签,然后继续在2.1.0上的 违约 分支。随后的承诺 违约 分支和从这一点开始的任何新功能分支将支持2.1.0。

此外,如果客户打电话 说有一个bug和小部件 机器在震动,烟雾在 开始翻滚,我是不是突然打开? widgets2.0,修复错误,部署到 服务器,然后提交/推送?

2.0.0的错误修复将通过更新到2.0.0变更集(即:标记),然后创建一个新的命名分支(可能调用 版本2.0.0 )这一分支机构从未完全并入 违约 分支机构现在已经转向2.1.0开发,该分支机构可能会无限期开放。它将包含任何基于2.0.0的错误修复。

一旦进行了2.0.0错误修复,有几种方法可以将特定的chagneset从2.0.0移动到 违约 (2.1.0)分支。可以创建特定变更集的修补程序并将其应用于 违约 分支,或者可以执行合并 版本2.0.0 到 违约 如果有道理的话。