提交-拉-合并-推还是拉-合并-提交-推？

我们几周前开始使用 Mercurial。大多数开发人员都遵循以下工作流程：

• 致力于某项功能
• commit -m“致力于功能 ABC”
• pull -u
• If branch
  • merge
  • 提交-m“合并”
  • push

今天，我们的一位开发人员建议我们这样做：

• 致力于某项功能
• pull -u
• if branch
  • merge
• commit -m“致力于功能 ABC”
• push

这样，日志中的“合并”变更集就会少得多。

我们中的一些人认为这只是一个问题偏好。我们中的一些人认为其中一个比另一个更好。我们没有太多经验，也不想承受滥用该工具的负面影响。因此，如果一种方法比另一种方法更可取，请告诉我原因。

我更喜欢你原来的程序，但有理智的人肯定会不同意。我考虑合并实际的软件开发工作，并希望让它成为我们流程中的一等公民。

在您的第二个/建议的程序中，风险在于拉动会执行一些您真正不想要的操作，然后您很难将其与您已经完成的工作分开。

对于那些无法忍受分支历史的人来说，通常首选的工作流程是：

• 致力于某项功能
• commit
• 拉--变基
• push

哪里的--rebase启用后，拉动时会出现选项变基扩展 https://www.mercurial-scm.org/wiki/RebaseExtension。我不喜欢 rebase，因为它在技术上重写了历史，这与 Mercurial 的工作原理相反，但在这一点上我属于迅速缩小的少数派。

最重要的是，如果您真的不想要分支历史记录，请使用 rebase ——不要更新为未提交的更改，因为很难撤消。