体系结构 – 功能,稳定版本等的Mercurial Repository结构
|
如果我认为这是适合的话,我将更具体地提出一个问题,如果我需要,或者将其变成社区维基,但我的问题是：
我的开发团队最近开始使用Mercurial(从颠覆开始),到目前为止我们都喜欢它.我想知道存储库架构是否存在“最佳实践”资源.我感兴趣的是,在处理功能和新版本时,保留repo的稳定副本(用于运送/紧急错误修复)的最佳方法是什么.我已经阅读了很多关于命名分支和克隆存储库的内容,我希望你们中的一些人可以对你们团队的工作有所了解. 在功能经过测试并准备好下一个版本后,更容易合并？我提到的两种方法有任何严重的缺点吗？还有其他的回购管理策略吗？ 我们正在接近我们的2.0.0版本的部署,并且我希望一旦它以一种新的hg工作方式出现就重新开始. 让我重新讲述一些我仍在努力的基础知识 – 假设我明天完成2.0.0 ……我想开始研究2.1.0,我该怎么办？克隆我的回购,将其命名为“working / projects / widgets2.1”并继续滚动,让我的“workin / projects / widgets2.0”准备好在bug修复情况下使用？ 此外,如果客户打电话并说有一个错误并且小部件机器正在摇晃并且烟雾开始滚滚,我是否会弹出打开小部件2.0,修复错误,部署到服务器,然后提交/推送？然后我回到widgets2.1并拉/合并那个bug修复？ 解决方法
据我所知,您所询问的是如何处理Mercurial中不同的开发分支.在您的示例中,您希望能够轻松地将修订发布到发行版,而无需处理自上次发布以来在开发分支中发生的所有事情.
在Mercurial中处理分支的方法有很多种.您可以使用单独的存储库,命名分支和Bookmarks扩展等.如何选择在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”中,并且可以继续处理下一个版本. 如果我们想要在更大的计划版本之外修复错误,我们可以通过几种方式实现.如果修复很小(几个提交)或者不涉及很多开发人员,我们可以直接提交“prod”,标记发布并发布它.之后我们从“prod”拉到“dev”,以确保在下一个版本中也有修复. 如果错误修复版本更大并且将花费更多时间,我们可以改为关闭“prod”的新分支,在那里发布我们的所有工作,然后将更改拉到“prod”.当它被释放到“prod”时,我们可以从“prod”“拉”到“dev”以获得那里的变化.然后可以删除特殊版本分支. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |