好的，我是Mercurial和版本控制分支的新手，所以我可能会对这里发生的事情有一个基本的误解 - 请善待......;）
我们是一个从事项目的小型开发团队（2名开发人员），我们需要实施可能需要数周或数月的相当重要的变更。同时，该程序是日常使用的，因此我们需要定期修补和修复。
由于重大更改的长期运行性质，我在默认分支（称为dev1）之外创建了一个分支。我想要定期将默认分支中的更改合并到dev1分支中，原因不需要在此重复。但是，我不希望dev1中的更改合并到默认分支中，直到开发的后期。
我已经尝试了几种不同的方法来做到这一点，但似乎合并总是影响两个分支。合并后，如果我更新为默认值，我现在已将dev1的更改合并到源中。
我可以使用相同的存储库在两个分支上工作吗？如果是这样，有人可以分享要使用的命令序列吗？如果没有，在我看来，我将无法将dev1分支推送到主仓库，直到它完成，这似乎不正确。
我们正在运行最新的TortoiseHg for Windows，而且我最喜欢的是图形工具。但是，我非常愿意在必要时进入命令行执行某些任务。
感谢您的帮助， 戴夫
答案 0 :(得分：2)
是的，您绝对可以使用Mercurial执行此操作。
首先，如果您不清楚（一段时间内不适合我），Mercurial中有3 types of 'branches'：
hg branch命令）我猜你使用了hg branch方法。请注意，这通常是不你想要的，因为该分支名称将永远存在于repo的历史中（好吧，有--close-branch选项，但仍然......）。< / p>
基本工作流程是：
hg up devbranch hg merge default或仅hg merge合并主分支用于处理默认分支：
hg up default 不要这样做：
hg up default hg merge 我怀疑您使用命令 hg merge而未指定分支名称。这将与任何其他头部合并，这可能是您想要的也可能不是。
修改：上述信息可能不是您的问题。当您的当前分支是默认分支时，您的问题可能正在运行合并。
您 想要从默认分支机构运行hg merge。
答案 1 :(得分：2)
这取决于您创建的分支类型。
如果您已创建命名分支，并且正在单个工作目录中工作，那么您需要使用一个工作流，但如果您克隆了生产存储库，则需要使用不同的工作流工作流程。
在这种情况下，您使用更新在default分支和dev1功能分支之间切换。
当您想要在default分支上工作时，请更新它，修复您的错误并提交这些更改。不要合并来自dev1分支的更改。
当您想要在dev1分支上工作时，请更新它，从默认分支合并您的错误修复程序，处理您的功能并在完成后提交。
如果您正在使用dev1分支机构并且同事修复了您需要的default中的错误，请提交您的工作，获取更改，合并它们然后恢复您的工作（有你可以在这里使用的快捷方式，但这样你可以在合并变得混乱的情况下退出合并）
注意：所有这些都假定您要在dev1和default分支之间切换时提交所有更改。
需要注意的重要一点是，只有将dev1分支合并到default分区时才能获得更改。如果您只将default合并到dev1然后，您的功能分支将与default保持同步，以便在准备好将功能部署到default分支时，您可以通过一个简单的合并操作来完成。
dev1 repo的未命名分支工作流程
此工作流程类似，但允许您同时处理default和dev1分支，而无需更新以在两者之间切换。
如果您想在default分支上工作，请使用存储库，其中tip是您的生产代码。修复您的错误，并像平常一样提交这些更改。
如果您想在dev1分支上工作，请使用存储库，其中tip是您的dev1功能分支。如果default存储库中有修复，请提取更改并将其合并到克隆中，但不要将合并更改集推回。当您要将功能部署到生产代码时，只需推回您的变更集。合并来自default的更改集后，您可以继续处理该功能。
如果您正在使用dev1分支，并且某位同事修复了您需要的default中的错误，请提交您的工作，将其更改从您的共享存储库中提取到default作品中克隆，然后将这些更改下拉到您的dev1功能克隆中，将它们合并，然后重新开始工作。
同样，需要注意的重要一点是，当您将dev1生成存储库推送到default时，只能从default中的default分支获得更改。如果您只将dev1个变更集合并到default克隆，那么您的功能分支将与default保持同步，以便在您准备好将该功能部署到{{1}时分支，你可以通过一个简单的推送操作来完成。
答案 2 :(得分：1)
# bang on dev1
# more banging on dev1
# someone beats on default for a while
# update to dev1
hg up dev1
# bring in the changes from default
hg merge -r default
# validate successful merge
hg commit -m "merging"
当您从默认值进行更改时，密钥将在dev1上提交。
请注意，我在这里使用了命名分支。
答案 3 :(得分：1)
这句话：
合并后，如果我更新为默认值，我现在已将dev1的更改合并到源中。
告诉我你做错了什么。你完全可以做什么，并行处理两个分支，从一个分支合并到另一个分支，而不影响两者。
重要的是要知道合并是一个定向合并。您将从一个分支合并到另一个分支，当您启动合并时，您应该 on 侧枝。
从方向在结果中起作用的意义上来说，方向性。对于文件的实际内容，合并的方向无关紧要，但您提交的新合并更改集将位于启动合并时所在的分支上（除非您覆盖。）
因此，首先更新到dev1的头部，然后与default合并，提交后，您应该在dev1分支上有一个新的变更集，但是{{1}应该不受干扰。
答案 4 :(得分：0)
这不仅仅是答案，而是......
我经常使用这个工作流程。我发现Transplant扩展名对于命名分支工作流程非常有用。 TortoiseHg支持它，因此您可以在TortoiseHg选项中启用它。它允许你从其他分支中挑选，这非常有用 - 特别是如果你经常提交错误的分支。