Mercurial：使用hg pull –rebase的问题的具体例子

我在hg pull –rebase中看到的主要问题是能够在没有任何撤消的情况下中断合并. DVCS模型基于明确跟踪历史记录的想法,并且通过说明我的所有更改都是在所有更改之后,即使我们真的同时处理它们,重新设置也会颠覆这个想法.而且因为我不知道你的更改是什么(因为我的代码基于早期的更改集),所以我很难知道我的代码在你的代码之上不会破坏某些东西.您还通过重新定位失去了分支功能,这实际上是DVCS背后的全部理念.

我们的工作流程(我们已经构建了一个entire Mercurial hosting system)基于保留多个克隆或分支存储库,就像我们所说的那样.每个开发人员或小团队都有自己的分支存储库,它只是“中央”存储库的一个副本.我的所有新功能和大错误修复都会进入我的个人分支机构.我可以对代码进行同行评审,一旦它被认为准备就绪,我就可以将它合并到中央回购中.

这给了我一些很好的好处.首先,我不会打破构建,因为我的所有更改都在他们自己的回购中,直到他们“准备好”.其次,如果我需要做一个单独的功能,或者如果我有更长时间运行的东西,我可以创建另一个分支回购,就像下一个主要版本一样.第三,如果存在需要快速修复的错误,我可以很容易地对中央仓库进行更改.

也就是说,您可以通过几种不同的方式使用此工作流程.最简单的,也是我开始使用的,只是保留单独的克隆.所以我将拥有网站中心,网站-tghw等.它运作良好,特别是因为你可以在本地推送和拉动它们.最近,我开始在同一个仓库中保留多个头,使用remotebranches扩展来帮助管理它们,而hg nudge则不要一次性推送所有内容.

当然,有些人不喜欢这个工作流程,通常是因为他们的Mercurial服务器很难制作服务器端克隆.在这种情况下,您还可以使用named branches来帮助保持您的功能.不幸的是,它们不像Git分支那么灵活(这就是为什么我们更喜欢分支回购)但是一旦你理解了如何关闭分支,它们就能很好地工作,以及为什么一旦启动分支就无法真正摆脱它们.

这有点长,所以我将鼓励你接受Mercurial提供的优质分支和合并(通过SVN).肯定存在学习曲线,但是一旦掌握了它,它确实会让事情变得更容易.