代码之家 › 专栏 › 技术社区 › Mark Borgerding

这种变化莫测的工作流程是否有缺点:被命名为“死”的分支头?

named branch workflow mercurial

Mark Borgerding · 技术社区 · 14 年前

我喜欢指定分支的灵活性,但我对头部的繁殖有一些顾虑。

即使分支关闭,它仍然会出现在头上。我对如何清除“Hg头”的输出有一个想法我问古鲁:“我错过了什么?”

首先,你可能会问,为什么我要完全隐藏一个命名分支的头?由于各种原因:

这个功能是个坏主意
这个功能是一个好主意,还没有准备好合并到Tip,但可能会在几个月内完成。
分支是旧标记版本的补丁版本

编辑: 事实证明,我使用的旧版Mercurial的症状是头部的增生。在新的Mercurial版本中,关闭分支会隐藏分支的头部。

我的想法是建立一个“死的”分支,所有这些封闭的分支头将被合并到这个分支上。
死掉的头将由变更集0作为父母,并且唯一的目的是捆绑现在不需要的流浪头。

死头只有其他死头子级,这些子级永远不会合并回默认分支。

3 回复 | 直到 12 年前

Amber 14 年前

你可以使用 hg commit --close-branch 要将分支标记为已关闭:

http://www.selenic.com/mercurial/hg.1.html#commit

关闭的分支不会出现在 hg branches 或 hg heads 默认情况下(仅当 -c / --closed 选项是指定的),所以我不确定您如何看到“杂乱”?

通过合并你到底能得到什么?

user1804642 12 年前

似乎有一个不利的方面,留下死胡同,这是不是解决了后来版本的mercurial。

假设您有许多闭合的分支头,并且只有一个非闭合的活动分支。进一步假设在以后的某个时刻,您在非闭合头(rev good)的顶部进行了一次糟糕的提交(rev bad)。在推送之前,您希望克隆您的存储库,并删除错误的提交。这通常是一件简单的事情-

hg clone --rev good BadRepo FixedRepo

不幸的是,这并不能拉动封闭的分支头,因为它们不是Rev Good的祖先。已关闭的所有分支将不会在克隆的存储库中关闭。我用Mercurial 2.3.1测试过这个。

思想?

p.s.合并之前,hgflow扩展会关闭feature并释放分支。这样就避免了闭合头问题。

关于克隆是一个丑陋的方法,它已经相当好,很容易为我工作。克隆会将存储库替换为错误的提交。克隆是本地工作。那个坏的存储库被丢弃了。我通常意识到很快我就犯了一个错误。

-b选项只是通过使用分支名称而不是更改集标识符来重新表述--rev的一种方法。使用--rev选项确实会将整个拓扑树拉到修订下。如果修订是分支的头,那么--rev克隆与-b克隆相同。-B留下了和我用--rev选项描述的相同的问题。在原始存储库中关闭的分支如果保留为头,则会重新打开。

如果模式是离开封闭的头,那么他们很快就会大大超过相关的头。将这些闭包放入克隆中是一项相当大的工作,除非您执行完整的克隆。

user1804642 12 年前

我觉得我把水弄混了,为什么我要做一个部分的克隆人。我会更仔细地重申我对关闭头的关注。

对于从存储库X到存储库Y的任何部分克隆,如果存储库X中存在一个带有闭合头的分支B,并且该分支出于纯粹的拓扑原因被包含在克隆中,那么存储库Y中将不会关闭分支B。此外,如果合并模式通常离开闭合头,则闭合头的数量为订单开发时间。

这是我关心的问题,所以我在合并前关闭了分支。我使用hglow(http://nvie.com/posts/a-successful-git-branching-model)。可能的部分克隆是克隆开发分支,然后通过拉动主分支(例如,如果您希望消除死角)进行克隆。如果功能和发布分支在最终合并后关闭,那么这些分支将在克隆中重新打开。