Answers:
我这样处理：
在我的本地存储库中，即使正在尝试，我也会进行所有更改。如果我对实验没问题，并且已经过测试，则将其推送到远程存储库。如果不是，它将保留在我的本地存储库中（或返回旧版本）。
这个想法是，远程存储库仅包含我的项目的经过测试的有效版本。
我将添加几件事。
一种是建议一种可以明智地使用货架的工作流程，该流程是TortoiseHg的标准配置。
每当我想提交当前工作目录的一部分时，我都会搁置不想提交的更改，重新编译（以确保我没有搁置某些位，这会导致编译失败），然后运行测试。然后，我将提交完整的，经过测试的套件。最终，我会不遗余力地恢复所做的更改。
如果我要进行更永久的更改，比如说我希望开发机器上的配置文件始终指向本地主机端口3333而不是生产服务器，那么我会考虑使用Mercurial Queues扩展，该扩展随Mercurial和TortoiseHg一起提供。
我不认为未提交的更改本质上不是一件坏事。您指的是“无法与它们合并”-如果您对某个文件进行了未提交的更改，并且对该文件进行了更改并进行了更新，则Mercurial会像您已提交文件一样开始合并过程，然后请求合并。你的意思不同吗？
因此，对于您不想与其他开发人员共享的本地更改，您有两种方法。第一种是将更改保留在您的工作副本中，但不要将其推送；另一种是将它们放在工作副本之外。选择哪种取决于您是否要在工作时使这些更改可用。
如果将它们保留在工作副本中，则传入的更改将正常工作，因此您只需要避免创建外发的更改，那就意味着避免提交它们。如果文件是新文件，那很容易-就是不要hg add。如果已经对它们进行了跟踪，则可以使用专门将它们排除在提交之外hg commit --exclude foo.txt。如果您有大量要排除的文件，或者将它们从许多提交中排除（例如，对于本地配置文件的永久更改），请查看exclude扩展名。
如果您准备将更改移到一边，则还有另一组选项。最简单的事情就是简单地hg diff在文件上生成描述它们的补丁，并将其保存在安全的地方，然后hg patch --no-commit在需要更改时重新应用该补丁。您可以通过安装扩展架，阁楼扩展架或其他相对扩展来使此过程更平滑。您还可以使用queues扩展，但这是使用大锤破解。您甚至可以只提交更改，然后更新回父级并在那里进行其他工作，将更改保留在一个粗略的匿名分支中hg commit -m 'temporary branch' && hg up $(hg log -r 'parents(.)' --template '{node}')（尽管手动操作可能更容易！）。但是，您将必须注意不要推送该变更集。
两种基本方法用于分离开发流。
命名分支。这个想法是，您在自己的分支机构nmichaels_branch_of_awesome上工作。这样一来，您就可以提交更改而无需花费他人的工作。然后，在需要他们的工作时与其他人合并，当需要使用该功能时，您将转到更稳定的分支进行集成。我喜欢命名分支。
匿名克隆。这将为您的沙箱创建一个单独的存储库。在这里，您一直在玩，直到获得所需的内容，然后（可能）为提交做一个MQ补丁，并将其推到起点。我不喜欢这种方法，因为它需要目录管理以及可能的MQ工作，这可能很棘手。并与一些回购，他们可以开始获得只是一个小本大。也就是说，窑炉开发人员似乎更喜欢这种方法。