我听说如果我们正在开发一个功能，然后我们需要快速修复，我们可以进行临时克隆然后修复bug，并推送到中央仓库。
首先，是从中央仓库还是从我们当地的仓库克隆的临时仓库？
另外，将2或3个回购从中央仓库克隆到我们的硬盘驱动器是否好，所以如果我们使用本地仓库1处理功能，并且需要快速修复错误，那么我们可以去到本地回购2，执行hg pull，hg up，并修复错误，hg push并完成错误修复而不影响本地回购1？
因此我们将始终保留本地repo 1,2,3，以便我们将它们作为备用，而不需要每次都创建一个新的临时克隆，这可能非常耗时。
更新：我认为答案的一个建议做法是：只从中央仓库到本地仓库克隆一次（并将此本地仓库称为“主仓库”），然后从本地克隆repo“on demand”，修复tmp repo中的紧急bug，直接从tmp repo推回到中央远程仓库？但是，它不是说在开发过程中，我们应该经常提交（甚至在功能完全完成并且没有bug之前），所以如果我们从本地repo克隆到tmp repo，那么克隆不会包含那些提交的文件好？如果紧急修复需要修改处于“中间”状态的本地仓库中的文件（在开发过程中）会怎么样？
答案 0 :(得分：3)
我的做法是拥有中央存储库的“主”克隆，然后对于我正在处理的每个功能或错误修复，我克隆“主”。当我完成一个功能时，我将它推回到'主人'，然后当我确信我会推到中央reo时。
答案 1 :(得分：2)
答案实际上取决于将变更集推送到主仓库的成本有多高。
如果你的主回购只有很少（或没有）质量门，推动你的变更集对你和整个团队都很便宜。在这种情况下，您可以选择加入克隆主仓库，进行快速修复并将其重新推送，以便尽快恢复到团队的其他部分和自动构建（假设您已设置CI） ）。
如果您的主仓库具有复杂的质量门限（推送前伙伴测试/验证，自动集成回归，每日构建和自动化等），那么推动对主仓库的任何更改对您和您的团队来说都是非常昂贵的。在这种情况下，您应该考虑克隆主要本地存储库，进行修复，然后将其推回以与其他更改合并，以便在推回主存储库之前批量处理您的工作。
答案 2 :(得分：2)
我会疯狂地试图跟踪多个本地克隆的状态。按需克隆是要走的路。如果克隆速度很慢，您有两种选择：
如果网络连接速度缓慢，您可以设置一个自动镜像远程仓库的本地克隆，只要远程仓库获得变更集，就会急切地更新。
如果Mercurial固有的缓慢，也许您应该重新审视Mercurial是否在修订控制系统中提供您所需要的问题。
答案 3 :(得分：2)
绝对只能从主仓库克隆一次。然后在启动新功能时在本地按需克隆。从克隆的克隆直接推回到中央仓库。基本上，我的工作流程看起来像一个圆圈
Remote-Master - （克隆/拉动） - ＆gt; local-never-modified-clone - （clone / pull） - ＆gt; local-modified-clones - （推） - ＆gt;远程主站
这里的优点是克隆自己的本地克隆应该是即时的。在现代文件系统上，mercurial使用存储库文件的硬链接并仅在更改时将其分解，因此repo的第二个克隆（来自本地源）仅占用工作文件的空间。
从远程主服务器创建本地永不修改的克隆时，我使用clone -U来避免创建工作副本，所以我不想在那里工作。创建一个新的本地克隆用于工作只需要一两秒钟，所以只要你有一个从未修改过的本地克隆就可以克隆，就不需要保留一些。
答案 4 :(得分：2)
如果紧急修复需要怎么办？ 修改文件中的文件 处于“中间”的本地回购 国家（在发展中）？
然后，在克隆本地存储库之后，在开始处理导致“中间”状态的主分支之前检出过去的提交，修复错误并推回到远程主控。它看起来像这样：
@ (under development)
|
| @ (fixed a bug)
|/
|
o (last good commit)
|
或者，您可以克隆本地仓库，直到“最后一次良好提交”，不包括正在开发的那些（使用hg clone -r <rev>）。