没有部分提交的“Mercurial 方式”答案

【问题标题】：Doing without partial commits the "Mercurial way"没有部分提交的“Mercurial 方式”
【发布时间】：2011-03-02 01:45:41
【问题描述】：

Subversion 商店正在考虑改用 Mercurial，并试图提前弄清楚开发人员的所有抱怨将会是什么。这里有一个相当常见的用例，我不知道如何处理。

现在呢？

我查看了“Mercurial cherry picking changes for commit”和“best practices in mercurial: branch vs. clone, and partial merges?”，所有建议似乎都是不同复杂性的扩展，从记录和搁置到队列。

显然没有任何核心功能的事实让我怀疑这种工作方式在某种意义上是做错了。这个用例的类似 Mercurial 的解决方案是什么样的？

编辑添加： 相比之下，git 似乎是为这个工作流程设计的：git add 错误修复文件，不要 git add 任何其他东西（或 git reset HEAD 任何你可能已经拥有的东西已添加），git commit。

【问题讨论】：

【解决方案1】：

以下是我处理此案的方式：

在您的场景中，我会经常提交功能分支之外的分支。

当请求进来时，我会 hg up -r XYZ 其中 XYZ 是他们正在运行的版本号，然后分支一个新的功能分支（或up branchname，等等）。

执行工作，然后在工作测试后合并到稳定分支。

切换回我的工作并从顶部功能分支提交节点合并，从而整合两个工作流。

【讨论】：

【解决方案2】：

Mercurial 的许多有用功能以扩展的形式提供——不要害怕使用它们。

至于您的问题，record 提供了您所谓的部分提交（它允许您选择要提交的更改块）。另一方面，shelve 允许临时清理您的工作副本，同时将更改保留在本地。提交错误修复后，您可以取消搁置更改并继续工作。

解决此问题的规范方法（即仅使用核心）可能是进行克隆（请注意，本地克隆很便宜，因为创建的是硬链接而不是副本）。

【讨论】：

【解决方案3】：

您将克隆存储库（即在 SVN 术语中创建一个错误修复分支）并从那里进行修复。

或者，如果它确实是一个快速修复，您可以在提交时使用 -I 选项来显式签入单个文件。

【讨论】：

-I 的优点。实际上，现在我正在查看 hg 手册页，而不是仅仅处理那些浏览教程的人的抱怨，我不确定提交行为是否与我想象的 svn 不同。
-I 选项甚至不需要，你可以直接使用hg commit foo.c bar.h。如果你想做花哨的包含/排除过滤器，我认为-I 和-X 选项是你使用的东西。我个人从不使用它们，因为我的 shell 可以为我完成所需的 globbing。

【解决方案4】：

与任何 DVCS 一样，分支是您的朋友。以多种方式分支存储库是这些系统的基础。这是一个git model，您可能会考虑采用它，它也适用于 Mercurial。

【讨论】：

【解决方案5】：

除了what Santa said 关于分支是你的朋友...

小粒度提交是您的朋友。与其在单个提交中进行大量代码更改，不如在其自己的提交中更改每个逻辑上独立的代码。然后，在分支之间选择合并更改会容易得多。

【讨论】：

【解决方案6】：

不使用 Mq Extension 就不要使用 Mercurial（它在默认安装中预先打包）。除了解决您的特定问题之外，它还解决了许多其他一般问题，并且确实应该是您工作的默认方式（尤其是如果您使用的 IDE 不直接与 Hg 集成，则可以即时切换分支一种困难的工作方式）。

【讨论】：