我正在努力寻找适合我们工作方式的善变工作流程.
我目前偏爱每个功能的克隆,但这是从Subversion转变的心态的一个很大变化.我们在设置环境时的当前费用也存在问题.
使用hg pull --rebase似乎给了我们更多类似Subversion的工作流程,但是从阅读中我对使用它很谨慎.
我想我理解这些概念,我可以看到重写历史并不理想,但我似乎无法想出任何我个人认为不可接受的情景.
我想知道什么是'最糟糕'的情景,因为hg pull --rebase可以创造理论或经验.我想要具体的例子,而不是关于你是否应该"改写历史"的观点.并不是说我反对有意见的人,只是已经有很多人在互联网上表达,而没有很多例子支持他们;)
tgh*_*ghw 10
新的Mercurial转换需要学习的第一件事是提交不完整的代码.Subversion告诉我们你不应该提交破坏的代码.现在是时候忘掉这种习惯了.经常提交可以为您的工作流程提供更大的灵活性.
我看到的主要问题hg pull --rebase是能够在没有任何撤消的情况下中断合并.DVCS模型基于明确跟踪历史记录的想法,并且通过说明所有更改都来自所有更改之后,即使我们确实在同时处理它们,重新定义也会破坏该想法.而且因为我不知道你的更改是什么(因为我的代码基于早期的更改集),所以我很难知道我的代码在你的代码之上不会破坏某些东西.您还通过重新定位失去了分支功能,这实际上是DVCS背后的全部理念.
我们的工作流程(我们已经构建了一个完整的Mercurial托管系统)基于保留多个克隆或分支存储库,就像我们所说的那样.每个开发人员或小团队都有自己的分支存储库,它只是"中央"存储库的一个副本.我的所有新功能和大错误修复都会进入我的个人分支机构.我可以对代码进行同行评审,一旦它被认为准备就绪,我就可以将它合并到中央回购中.
这给了我一些很好的好处.首先,我不会破坏构建,因为我的所有更改都在他们自己的回购中,直到他们"准备好".其次,如果我需要做一个单独的功能,或者如果我有更长时间运行的东西,我可以创建另一个分支回购,就像下一个主要版本一样.第三,如果存在需要快速修复的错误,我可以很容易地对中央仓库进行更改.
也就是说,您可以通过几种不同的方式使用此工作流程.最简单的,也是我开始使用的,只是保留单独的克隆.所以,我要website-central,website-tghw等它运作良好,特别是因为你可以把本地和它们之间拉.最近,我开始在同一个仓库中保留多个头,使用remotebranches扩展来帮助管理它们,并且hg nudge以防止一次性推送所有内容.
当然,有些人不喜欢这个工作流程,通常是因为他们的Mercurial服务器很难制作服务器端克隆.在这种情况下,您还可以查看使用命名分支来帮助保持您的功能.不幸的是,它们不像Git分支那么灵活(这就是为什么我们更喜欢分支回购)但是一旦你理解了如何关闭分支,它们就能很好地工作,以及为什么一旦启动它们就无法真正摆脱它们.
这有点长,所以我将鼓励你接受Mercurial提供的优质分支和合并(通过SVN).肯定存在学习曲线,但是一旦掌握了它,它确实会让事情变得更容易.
| 归档时间： |
|
| 查看次数： |
2566 次 |
| 最近记录： |