Mercurial 工作流程：为什么我似乎将所有内容都提交了两次？答案

【问题标题】：Mercurial workflow: why do I seem to commit everything twice?Mercurial 工作流程：为什么我似乎将所有内容都提交了两次？
【发布时间】：2012-08-23 09:45:49
【问题描述】：

我正在尝试掌握 Mercurial 的基础知识，所以请多多包涵。 :) 我目前的工作流程如下：

做一些工作，直到我准备好提交或需要其他人的更改
拉
此时我想将我的工作与最新的变更集合并并提交，但是 Mercurial 坚持要求我在合并之前提交
所以它就像“提交、合并、提交”，我基本上将所有内容提交两次，在两个变更集中编写相同的注释并一次推送两个变更集

是这样的吗？每次合并是否可能只有一个变更集来自我？真的可取吗？

我已经阅读了很多在线手册，但仍然觉得我对这个过程没有深入的了解。欢迎所有的cmets。谢谢！

编辑：原来我不知道更新可以将传入的更改与未提交的编辑合并。

【问题讨论】：

another thread hereabouts 可能有助于回答您的问题。
你应该少拉一点:)，一天一两次就足够了。通常不需要在每次提交后拉取，特别是如果你保持提交量很小。

标签： mercurial merge workflow commit

【解决方案1】：

此工作流程将阻止历史记录中的合并，但您仍按如下所述进行合并：

做一些工作，直到您准备好提交或需要其他人的更改。
hg pull
hg update（注意：hg pull -u 一步完成此操作和上一步操作。

在hg update 期间，您未提交的更改将与您当前分支的新提示合并。您仍然需要解决任何冲突。

hg commit 准备就绪。

我仍然建议您在拉取/合并之前先提交大量更改，因为如果合并失败，通过更新到该更改集来重新开始会更容易。

保持hg pull 和hg update 分开允许您查看传入的变更集并预测合并将如何进行。

【讨论】：

这是我更喜欢避免太多合并变更集的方法。正如 Mark 解释的那样，hg update 进行了隐式合并，因此您可以将更改和合并作为单个变更集提交。
谢谢，我认为更新总是意味着干净的更新......会试试看。

【解决方案2】：

感觉奇怪的原因是你延迟了提交，直到你想与其他人整合。

分布式版本控制的一大特点是提交是本地的。因为它们是本地的，所以您应该经常提交 — 每次完成一小部分一致的工作时提交。您的提交不会立即影响其他人，因此您不会通过进行许多小提交来打断他们。

如果您开始进行更多提交，您会发现您的工作流程变为：

$ hg commit -m "Refactoring for Issue123"
$ hg commit -m "Basic functionality for Issue123"
$ hg commit -m "Fixed off-by-one error (Issue123)"
$ hg commit -m "Finished implementing Issue123"
$ hg commit -m "Added more tests for Issue123"
$ hg commit -m "Begin use new function from Issue123"
$ hg pull
$ hg merge
$ hg commit -m "Merge"

这里合并提交与“真实”提交的比率要合理得多。

很多人（包括我自己）喜欢使用rebase extension 来完全避免合并。该扩展通过伪造历史来线性化提交，因此看起来您在使用hg pull 拉下的变更集之后进行了四次提交。工作流程中唯一的变化是你 hg rebase 而不是上面的 hg merge 然后跳过最后的提交。

【讨论】：

感谢您的洞察力，这对我来说是一个新想法。

【解决方案3】：

合并总是在 Mercurial 中创建一个单独的变更集。

此外，只要您的本地存储库中有未提交的内容，就无法进行合并。
所以解决办法是先commit，然后再pull和merge。
这将始终导致两个变更集，而不是一个。
（...因为合并总是会创建一个单独的变更集）

但是你不会两次提交相同的东西，尤其是你不应该两次写相同的提交信息：

第一次提交是您实际更改的内容（“修复了 foo 栏中的错误”）。
第二次提交只是合并（TortoiseHG 实际上用“Merge”预先填充了提交消息，99% 的时间我都这样）。

【讨论】：