我正在努力寻找适合我们工作方式的善变工作流程。
我目前偏爱每个功能的克隆，但这是从Subversion转变的心态的一个很大变化。我们在设置环境时的当前费用也存在问题。
使用hg pull --rebase似乎给了我们更多类似Subversion的工作流程，但是从阅读中我很担心使用它。
我想我理解这些概念，我可以看到重写历史并不理想，但我似乎无法想出任何我个人认为不可接受的情景。
我想知道什么是'最糟糕的'场景，hg pull --rebase可以创造理论或经验。我想要具体的例子，而不是关于你是否应该“改写历史”的观点。并不是说我反对有意见的人，只是已经有很多人在互联网上表达，而没有很多例子支持他们;）
答案 0 :(得分：10)
新的Mercurial转换需要学习的第一件事就是提交不完整的代码。 Subversion告诉我们你不应该提交破坏的代码。现在是时候忘掉这种习惯了。经常提交可以为您的工作流程提供更大的灵活性。
我在hg pull --rebase看到的主要问题是能够在没有任何撤消的情况下中断合并。 DVCS模型基于明确跟踪历史记录的想法，并且通过说明我的所有更改都是在所有更改之后，即使我们真的同时处理它们，重新设置也会颠覆这个想法。而且因为我不知道你的更改是什么（因为我的代码基于早期的更改集），所以我很难知道我的代码在你的代码之上不会破坏某些东西。你也会通过变基来失去分支能力，这实际上是DVCS背后的全部理念。
我们的工作流程（我们已经构建了entire Mercurial hosting system）基于保留多个克隆或分支存储库，就像我们所说的那样。每个开发人员或小团队都有自己的分支存储库，它只是“中央”存储库的一个副本。我的所有新功能和大错误修复都会进入我的个人分支机构。我可以对代码进行同行评审，一旦它被认为准备就绪，我就可以将它合并到中央回购中。
这给了我一些很好的好处。首先，我不会打破构建，因为我的所有更改都在他们自己的回购中，直到他们“准备好”。其次，如果我需要做一个单独的功能，或者如果我有更长时间运行的东西，我可以创建另一个分支回购，就像下一个主要版本一样。第三，如果存在需要快速修复的错误，我可以很容易地对中央仓库进行更改。
也就是说，您可以通过几种不同的方式使用此工作流程。最简单的，也是我开始使用的，只是保留单独的克隆。所以我会website-central，website-tghw等。它运作良好，特别是因为你可以在本地推送和拉动它们。最近，我开始在同一个仓库中保留多个头，使用remotebranches扩展来帮助管理它们，hg nudge不要一次性推送所有内容。
当然，有些人不喜欢这个工作流程，通常是因为他们的Mercurial服务器很难制作服务器端克隆。在这种情况下，您还可以使用named branches来帮助保持您的功能。不幸的是，它们不像Git分支那么灵活（这就是为什么我们更喜欢分支回购）但是一旦你理解了如何关闭分支，它们就能很好地工作，以及为什么一旦启动分支就无法真正摆脱它们。< / p>
这有点长，所以我会鼓励你接受Mercurial提供的优质分支和合并（通过SVN）。肯定存在学习曲线，但是一旦掌握了它，它确实会让事情变得更容易。
答案 1 :(得分：2)
从问题评论中，你的根本问题是你有开发人员同时处理几个功能/错误修复/问题，并且在他们的工作目录中有未提交的工作以及一些已经准备好被推回到工作目录的已完成的工作。中央存储库。
这是一个非常好的交流，可以很好地解决这个问题并带来前进的多种方式。
http://thread.gmane.org/gmane.comp.version-control.mercurial.general/19704
您可以通过各种方式保持未提交的更改，例如：通过拥有a separate clone to handle merges，但我的建议是尽可能多地采用分布式的工作和提交方式 - 如果你真的觉得有必要将最后几个本地提交合并到一个变更集中（使用MQ，例如）推前。