提交拉合并推或拉合并提交推? [英] commit-pull-merge-push or pull-merge-commit-push?

问题描述

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

We started using Mercurial a several weeks ago. Most developers follow this workflow:

• 致力于一项功能
• commit -m已使用功能ABC"
• 拉-u
• 如果分支
  • 合并
  • 提交-m合并"
  • 推
  • work on a feature
  • commit -m "Worked on feature ABC"
  • pull -u
  • If branch
    • merge
    • commit -m "Merge"
    • push

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

    Today, one of our developer suggested that we do:

    • 致力于一项功能
    • 拉-u
    • if分支
      • 合并
      • work on a feature
      • pull -u
      • if branch
        • merge

        这样，我们的日志中的合并"变更集要少得多.

        That way, we have a lot less "Merge" changesets in the log.

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

        Some of us think it's just a matter preference. Some of us think one is better than the other. We don't have much experience and don't want to live the downsides of misusing the tool. So if one approach is more advisable then the other, please let me know why.

        推荐答案

        我更喜欢您的原始过程，但是理性的人当然可以不同意.我考虑合并一个实际的软件开发工作，就像让它成为我们流程中的一等公民一样.

        I like your original procedure more, but reasonable people can certainly disagree. I consider merging an actual piece of software development work and like having it be a first class citizen in our process.

        在第二步/建议的过程中，风险是拔出的东西确实是您不想要的，然后您很难将其与已经完成的工作分开.

        In your second/suggested procedure the risk is that the pull does some stuff you really don't want and then you have a very hard time separating it from the work you've already done.

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

        For people who just can't stand branchy history the usual preferred workflow is:

        • 致力于一项功能
        • 提交
        • 拉--rebase
        • 推

        在启用 rebase扩展后，下拉菜单中出现--rebase选项的地方 .我不喜欢变基，因为从技术上讲，它是改写历史，与应该如何使用汞相反，但是在那一点上，我处于迅速萎缩的少数群体.

        where the --rebase option appears on pull after you enable the rebase extension. I'm not a fan of rebase because it's technically rewriting history which is antithetical to how mercurial is supposed to work, but I'm in a rapidly shrinking minority on that point.

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

        Bottom line, if you really don't want a branchy history use rebase -- don't update into uncommitted changes as it's hard to undo.

        这篇关于提交拉合并推或拉合并提交推?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！