我们几周前开始使用 Mercurial。大多数开发人员都遵循此工作流程：
今天，我们的一位开发人员建议我们这样做：
这样，我们在日志中的“合并”变更集就会少很多。
我们中的一些人认为这只是一种偏好。我们中的一些人认为一个比另一个更好。我们没有太多经验，也不想承受滥用该工具的不利影响。因此，如果一种方法比另一种更可取，请告诉我原因。
【问题讨论】：
我更喜欢你原来的程序，但理性的人当然可以不同意。我考虑合并一个实际的软件开发工作，并希望它成为我们流程中的一等公民。
在您的第二个/建议的过程中，风险在于 pull 会做一些您真正不想要的事情，然后您很难将其与您已经完成的工作区分开来。
对于那些无法忍受复杂历史的人来说，通常首选的工作流程是：
启用rebase extension 后，--rebase 选项出现在拉取时。我不喜欢 rebase，因为它在技术上重写了历史，这与 mercurial 应该如何工作是对立的，但我在这一点上处于迅速缩小的少数。
底线，如果您真的不想要分支历史，请使用 rebase - 不要更新为未提交的更改，因为它很难撤消。
【讨论】：
我会采用您的第一个工作流程。我对第二个选项的主要反对意见是，如果您在提交之前尝试合并，那么当出现问题（有时确实会发生）时，没有简单的方法可以退出合并，因此您可以重新开始。
如果您遇到与功能 A 的合并冲突，并且想向负责功能 A 的开发人员询问有关此问题的信息，但他正在午休，这可能会特别方便。使用您的第一个工作流程，您可以中止合并并继续进行，直到该开发人员回来并且您准备好再次合并。对于第二个工作流程，您只是有点卡住了，不得不去寻找其他事情做（或者制作另一个存储库克隆并在该存储库中工作，直到您可以合并，但这对我来说似乎更糟）。
【讨论】：
这行不通：
如果您有本地更改，则可能不会合并。你/可以/做的是：
您可能还想调查hg fetch，它是一个随机附带的可选插件，可在同一步骤中执行拉取/合并。如果您在提交之前忘记拉动，这对您有好处。
【讨论】：