版本控制 – 管理Mercurial中的代码：如何还原单个文件,“标记”
|
更新：我们最终使用的流程非常像
this schema(感谢
neuro的链接).我们将存储库按摩到默认稳定的状态(并且与我们的生产环境具有相同的代码),我们有一个开发分支,新功能的分支和发布的释放分支.一切似乎都很完美.
背景故事 我们的团队最近从使用SVN(使用ToroiseSVN Windows客户端)到Mercurial(使用TortoiseHg Windows客户端)进行版本控制.我们已成功导出SVN存储库并将其导入Mercurial存储库. 我们现在有一个Mercurial存储库,我们可以在其中查看修订的整个历史记录(Mercurial中的更改集). 我们过去是怎么做到的 过去的生活更简单;我们的开发过程并不像现在这样真正的多流.行李箱用于保存所有代码 – 甚至是仍然在飞行中的变化(只要它没有破坏行李箱).在使用SVN管理版本时,我们会检查主干(包含所有代码),恢复我们不希望作为发布的一部分的各个更改,并为其创建标记. 用SVN编写我们想要的代码很容易.错误修复以前的版本并确保它是主干的一部分也很简单. 我们现在在做什么 在Mercurial中,我们需要能够获得“trunk”的快照(Mercurial中的默认值),并恢复个别更改.我们可以使用hg revert来做到这一点. 为了对此进行快照,我们创建了一个“命名分支” – 现在我们称之为Build-4.0.1. 挑战出现的地方 当在Build-4.0.1中发现错误时,开发将继续默认进行.我们假设该错误存在于其中一个恢复文件中.我们从Build-4.0.1的分支更改代码,创建一个新的“命名分支”(Build-4.0.2),并希望将其合并回默认值,而不会将恢复的代码推到新代码的顶部.我们怎样才能做到这一点？ 或者,是否有更好的工作流程来管理Mercurial中的版本和代码？我非常喜欢这个wonderful SO answer on managing release branches的外观,虽然我不确定我们如何从我们现在的状态转换到它(默认情况下是飞行中的东西). 注意：我已经查看了Transplant extension,但尚未使用它 – 它可以成为解决这一挑战的一部分吗？ 解决方法
好吧,首先,你对revert的使用对我来说似乎很奇怪.通常,它用于将对工作副本所做的修改还原为存储库的版本.
将工作副本向后移动的常用方法是更新： hg update -r 1234 从那里,你可以标记,修改,提交等 要合并,您只需将发布分支合并到默认分支.它将像魅力一样工作,除非它是不同/旧版本. 移植工作正常,但做一些与合并有点不同的东西：它将您的变更集作为“差异”并将其应用为新的修改. 要管理您的版本,您可以查看其他答案(由我)： How to use mercurial for release management? 我们使用的是一个克隆/主分支,它拥有最稳定的版本,在某些时候发布.在这个克隆：分支,我们可以修复关键错误(修补程序).同时,我们使用dev clone / branch来开发.一旦从stable到dev完成,修补程序就会合并.当前开发完成后,我们将dev合并为stable / default. 这个schema很好理解:) 祝好运 ！ （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |