为什么有时我需要在拉取后合并而不是简单地更新？答案

【问题标题】：Why do I sometimes need to merge after a pull rather than simply updating?为什么有时我需要在拉取后合并而不是简单地更新？
【发布时间】：2011-08-14 00:48:18
【问题描述】：

当我第一次开始使用 hg 时，update 似乎具有一种近乎神奇的能力，可以接受新拉取的更改并将它们集成到我的本地 repo 中。然而，最近，我注意到即使我的本地更改与从其他地方新提取的更改不冲突，我总是必须合并，从而导致一个额外的更改集复制了我在其中一个中已经拥有的一堆更改本地代码行（标题）。

我想了解是什么促使 hg 需要合并，而不是仅仅将所有更改与更新一起消除。冲突显然需要合并。还有什么？

【问题讨论】：

标签： mercurial merge

【解决方案1】：

合并与更新的需要不是关于更改是否冲突，而是关于您的提交历史记录中是否存在拆分。如果你有这样的历史：

[A]--[B]--[C]--UNCOMMITTEDCHANGESHERE

然后你拉下 --[D] 当你更新时，你未提交的更改将与 D 合并。

如果您已经承诺，那么您：

[A]--[B]--[C]--[E]

你拉你就会有：

[A]--[B]--[C]--[E]
             \
              -[D]

而且你需要合并才能得到一个单一的头部。

为了记录，这是一个更好的主意。使用未提交的更改进行更新是不可逆的操作，这总是有点可怕。如果您已提交，您可以随时撤消/重做合并，直到您对组合感到满意为止。

附：有人可能会建议使用 fetch 扩展名，但他们大错特错。

【讨论】：

所以在一个相关的注释上——如果我变基而不是合并，那是否保持一个连续的代码行？我注意到如果您希望能够推回 SVN，hgsubversion 需要此功能，鉴于此信息，这更有意义。
变基确实产生了线性历史，但它是一个有点不诚实的线性历史（因为发展不是线性的；它是并发的）。有些人更喜欢这样，但我更喜欢我的历史真实准确地反映事情发生的顺序。归根结底，这完全取决于个人偏好（或团队政策）。
出于好奇，为什么 fetch 是“大错特错”？我知道它已被弃用，但不知道为什么
Fetch 合并了 3 个完全独立的操作（pull、update 和 merge），同时产生了一个无用的提交消息。 DVC 在这里和那里移动变更集（在 mercurial 中推/拉和使用 git 推/取）在逻辑上与更新工作目录和合并头部不同。当您使用一个命令完成所有 3 项操作时，您会得到糟糕的错误语义、错误的提交消息，并且如果您开始可能会混淆哪些命令会更改本地文件、本地存储库和远程存储库。