Subversion商店考虑转向Mercurial,试图提前弄清楚开发商的所有投诉是什么。这里有一个相当常见的用例,我看不出如何处理。
现在是什么?
我查看了“Mercurial cherry picking changes for commit”和“best practices in mercurial: branch vs. clone, and partial merges?”,所有建议似乎都是不同复杂程度的扩展,从记录和搁置到队列。
显然没有任何核心功能的事实使我怀疑在某种意义上这种工作风格是做错了。这个用例的Mercurial式解决方案会是什么样的?
编辑添加: git,相比之下,似乎是针对此工作流程设计的:git add
错误修正文件,不要git add
其他任何内容(或{{1}你可能已经添加的任何内容),git reset HEAD
。
答案 0 :(得分:8)
以下是我将如何处理案件:
在你的场景中,我会频繁地从功能部门的分支机构提交。
当请求进来时,我会hg up -r XYZ
其中XYZ是他们正在运行的转号,然后从中分支一个新的功能分支(或up branchname
,无论如何)。
执行工作,然后在测试工作后合并到稳定分支。
切换回我的工作并从顶部功能分支提交节点合并,从而整合两个工作流。
答案 1 :(得分:6)
Mercurial的许多有用功能都以扩展的形式提供 - 不要害怕使用它们。
至于你的问题,record
提供你所谓的部分提交(它允许你选择你想要提交的更改)。另一方面,shelve
允许临时使您的工作副本清洁,同时在本地保留更改。提交错误修复后,您可以取消更改并继续工作。
解决此问题的规范方法(即仅使用核心)可能是制作克隆(请注意,当创建硬链接而不是副本时,本地克隆很便宜。)
答案 2 :(得分:3)
您将克隆存储库(即以SVN术语创建错误修复分支)并从那里执行修复。
或者,如果它确实是一个快速修复,您可以在提交时使用-I选项显式签入单个文件。
答案 3 :(得分:3)
与任何DVCS一样,分支是您的朋友。以多种方式对存储库进行分支是这些系统的基础。以下是您可能会考虑采用的git model,它与Mercurial的效果非常好。
答案 4 :(得分:1)
除了what Santa said关于分支是你的朋友......
小粒度提交是你的朋友。而不是在单个提交中进行大量代码更改,而是使每个逻辑上自包含的代码在其自己的提交中更改。然后,可以更容易地选择更改以在分支之间进行合并。
答案 5 :(得分:1)
请勿在不使用Mq Extension的情况下使用Mercurial(它在默认安装中预先打包)。除了解决您的特定问题之外,它还解决了许多其他常见问题,并且应该是您工作的默认方式(特别是如果您使用的IDE不直接与Hg集成,可以实时切换分支一种困难的工作方式)。