我对Mercurial相对较新，我的团队正在尝试将其作为Subversion的替代品。
如何将单个文件提交并推送到另一个存储库，同时保留我的工作目录中的其他修改未提交（或者至少不推送到其他存储库）？
对于我们进行数据库迁移，会发生这种情况。我们希望将迁移提交到源代码控制，以便DBA可以在我们处理代码修改时查看和编辑它，以便与数据库迁移一起进行。这些变化还没有准备好，所以我们不想把它们全部推出去。
在颠覆中，我只是这样做：
svn add my_migration.sql
# commit only the migration, but not the other files I'm working on
svn commit -m "migration notes" my_mygration.sql
并继续在当地工作。
当我将它推送到另一个存储库时，这对mercurial不起作用，如果我没有删除它的更改，它希望我将它们拉下来，合并它们并提交合并到存储库。合并后提交不允许您省略文件，因此它会强制您提交本地存储库中的所有内容。
我能想到的最简单的事情是将文件提交到我的本地存储库，克隆我的本地存储库，从实际存储库中获取任何新的更改，合并它们并提交合并，然后将我的更改推送出去。 / p>
hg add my_migration.sql
hg commit -m "migration notes" my_migration.sql
cd ..
hg clone project project-clone
cd project-clone
hg fetch http://hg/project
hg push http://hg/project
这很有效，但感觉我错过了一些更简单的东西，某种方式告诉mercurial忽略我工作目录中已有的文件，只需进行合并并发送文件。我怀疑mercurial队列可以做到这一点，但我还没有完全了解mq。
答案 0 :(得分：39)
我最初提出这个问题差不多2年了。我现在做的不同（正如我在上面的问题上面的评论中提到的那样）。我现在要做的是将我的更改提交到我本地仓库中的一个文件（你可以使用hg记录扩展只提交一个文件片段）：
hg commit -m "commit message" filename
然后就推开。
hg push
如果存在冲突，因为我已经对我需要首先合并的仓库进行了其他更改，我会更新到父版本（如果您不知道它是什么，请查看“hg parents -r。” ），我在那里进行其他更改，所以我有两个脑袋。然后恢复到原始单个文件提交并将更改拉/合并到该版本中。然后用
推出更改hg push --rev .
仅推出单个文件和该修订的合并。然后你可以合并你在当地的两个头。
这种方式摆脱了mq的东西和被拒绝的帅哥的潜力，并保持一切由源控制跟踪。如果您以后决定不需要它们，也可以“关闭”修订版。
答案 1 :(得分：31)
有一个Mercurial功能可以实现搁置和取消搁置的命令，它们为您提供了一种交互式方式来指定要存储的更改，直到稍后：Shelve。
然后，您可以hg shelve和hg unshelve临时存储更改。它允许您在“补丁大块”级别工作来挑选和选择要搁置的项目。它似乎没有搁置一个已经列出添加的文件，只有已经在repo中修改的文件。
它包含在Mercurial中作为“扩展”，这意味着你必须在你的hg配置文件中启用它。
Mercurial的旧版本的注释（包括搁置之前 - 不再需要）：
我没有看到任何一些谷歌搜索的安装说明，所以这里是我用来使其工作的组合：
获取：
hg clone http://freehg.org/u/tksoh/hgshelve/ hgshelve
项目中唯一的（当前）文件是hgshelve.py文件。
修改你的〜/ .hgrc以添加shelve扩展，指向你克隆回购的地方：
[extensions]
hgshelve=/Users/ted/Documents/workspace/hgshelve/hgshelve.py
答案 2 :(得分：10)
tl; dr：我原来的解释看起来很复杂，但我希望它能完整地解释如何使用补丁队列。这是简短版本：
$ hg qnew -m "migration notes" -f migration my_migration.sql
$ hg qnew -f working-code
# make some changes to your code
$ hg qrefresh # update the patch with the changes you just made
$ hg qfinish -a # turn all the applied patches into normal hg commits
Mercurial Queues使这类事情变得轻而易举，它使更改集的操作变得更加复杂。这值得学习。
在这种情况下，首先您可能希望在下拉更改之前保存当前目录中的内容：
# create a patch called migration containing your migration
$ hg qnew -m "migration notes" -f migration.patch my_migration.sql
$ hg qseries -v # the current state of the patch queue, A means applied
0 A migration.patch
$ hg qnew -f working-code.patch # put the rest of the code in a patch
$ hg qseries -v
0 A migration.patch
1 A working-code.patch
现在让我们对工作代码做一些额外的工作。我将继续做qseries只是为了明确，但是一旦建立了补丁队列的心智模型，你就不必继续查看列表了。
$ hg qtop # show the patch we're currently editing
working-code.patch
$ ...hack, hack, hack...
$ hg diff # show the changes that have not been incorporated into the patch
blah, blah
$ hg qrefresh # update the patch with the changes you just made
$ hg qdiff # show the top patch's diff
由于您的所有工作现在都已保存在修补程序队列中，因此您可以在应用远程更改后取消应用这些更改并将其还原。通常要取消应用所有补丁，只需执行hg qpop -a。只是为了显示对补丁队列的影响，我会一次一个地弹出它们。
$ hg qpop # unapply the top patch, U means unapplied
$ hg qseries -v
0 A migration.patch
1 U working-code.patch
$ hg qtop
migration.patch
$ hg qpop
$ hg qseries -v
0 U migration.patch
1 U working-code.patch
此时，就好像您的目录中没有任何更改。做hg fetch。现在，您可以重新启动修补程序队列更改，并在存在任何冲突时合并它们。这在概念上有点类似于git的rebase。
$ hg qpush # put the first patch back on
$ hg qseries -v
0 A migration.patch
1 U working-code.patch
$ hg qfinish -a # turn all the applied patches into normal hg commits
$ hg qseries -v
0 U working-code.patch
$ hg out
migration.patch commit info... blah, blah
$ hg push # push out your changes
此时，您已经推出了迁移，同时保留了其他本地更改。您的其他更改位于队列中的修补程序中。我使用补丁队列进行大部分个人开发，以帮助我更好地构建我的更改。如果你想摆脱补丁队列并恢复正常的风格，你必须导出你的变化，并在“正常”的情况下重新导入它们。
$ hg qpush
$ hg qseries -v
0 A working-code.patch
$ hg export qtip > temp.diff
$ rm -r .hg/patches # get rid of mq from the repository entirely
$ hg import --no-commit temp.diff # apply the changes to the working directory
$ rm temp.diff
我非常沉迷于用于开发的补丁队列，mq是最好的实现之一。同时进行多项更改的能力确实可以改善您的提交的重点和清洁程度。需要一段时间才能习惯，但它在DVCS工作流程中表现非常出色。
答案 3 :(得分：3)
如果您不想依赖扩展，另一个选择是在本地保留您的上游存储库的克隆，仅用于这些类型的集成任务。
在您的示例中，您可以简单地将您的更改/合并到集成/上游存储库中，并将其直接推送到远程服务器。
答案 4 :(得分：2)
我通常使用的是提交单个文件：
hg commit -m "commit message" filename
如果以后发生合并冲突，我仍然没有准备好提交更改，请按照以下步骤操作：
1）创建补丁文件。
hg diff > changes.patch
2）仅在检查补丁文件后，还原所有未完成的未提交更改。
hg revert --all
3）拉，更新并合并到最新版本
hg pull -u
hg merge
hg commit -m "local merge"
4）现在只需导入补丁并进行更改即可。
hg import --no-commit changes.patch
请记住在自动提交更改时使用-no-commit标志。
答案 5 :(得分：1)
既然你说最容易，我甚至在提交整个文件时经常使用hg commit -i（ - interactive）。使用--interactive，您只需选择所需的文件，而不是在命令行上键入整个路径。作为额外的奖励，您甚至可以选择性地在文件中包含/排除块。
然后只需hg push来推送新创建的提交。
我在此答案中详细介绍了如何使用hg commit --interactive：https://stackoverflow.com/a/47931672/255961