几个星期前我们开始使用Mercurial。大多数开发人员都遵循此工作流程：
今天，我们的一位开发人员建议我们这样做：
这样，我们在日志中的“合并”变更集就少了很多。
我们中的一些人认为这只是一个问题偏好。我们中的一些人认为一个比另一个好。我们没有太多经验，也不想生活滥用工具的缺点。因此，如果一种方法比另一方更可取，请告诉我原因。
答案 0 :(得分：21)
我更喜欢你原来的程序，但合理的人肯定不同意。我认为合并一个实际的软件开发工作，就像在我们的过程中让它成为一等公民一样。
在你的第二个/建议的程序中，风险是拉动你做了一些你真正不想要的东西，然后你很难将它与你已经完成的工作分开。
对于那些无法忍受冗长历史的人来说，通常的首选工作流程是：
启用rebase extension后，--rebase选项出现在拉动状态。我并不喜欢变形，因为它在技术上重写了历史，这与多变量应该如何起作用是对立的，但在这一点上，我处于一个迅速萎缩的少数。
最重要的是，如果你真的不想让一个分支历史记录使用rebase - 请不要更新为未提交的更改，因为它很难撤消。
答案 1 :(得分：4)
我会选择你的第一个工作流程。我对第二个选项的主要反对意见是，如果你在提交之前尝试合并，那么当出现问题（这种情况不时发生）时，没有简单的方法可以退出合并，这样你就可以重新开始了。
如果你遇到与功能A的合并冲突，并且想要询问开发功能A的开发人员，那么这可能会特别方便，但他正在午餐休息时间。使用您的第一个工作流程，您可以中止合并，然后继续，直到开发人员回来并且您已准备好再次合并。使用第二个工作流程，你只是有点困难，必须去寻找别的东西（或者再创建一个存储库并在那个工作中使用，直到你可以合并，但这对我来说似乎更糟）。
答案 2 :(得分：1)
这不起作用：
如果您有本地更改，则可能无法合并。您/可以/做的是：
您可能还想调查hg fetch，它是随附的mercurial可选插件，它在同一步骤中执行pull / merge。如果你在提交之前忘了拉，这对你有好处。