我正在努力寻找适合我们工作方式的多变的工作流程。
我目前倾向于对每个功能进行克隆，但这是从 Subversion 转变而来的心态上的很大变化。我们在设置环境方面的当前费用也会有问题。
使用 hg pull --rebase 似乎为我们提供了更多类似于 Subversion 的工作流程，但从阅读中我对使用它持谨慎态度。
我想我理解这些概念，我可以看到重写历史并不理想，但我似乎无法提出任何我个人认为 Not Acceptable 场景。
我想知道 hg pull --rebase 可以从理论或经验中创造出的“最坏”场景是什么。我想要具体的例子，而不是关于你是否“应该”重写历史的看法。并不是说我反对人们发表意见，只是互联网上似乎已经有很多人表达了他们的观点，而没有很多例子来支持他们；)
最佳答案
新 Mercurial 转换者需要学习的第一件事是适应提交不完整的代码。 Subversion 告诉我们你不应该提交损坏的代码。现在是时候改掉这个习惯了。频繁提交可为您的工作流程提供更大的灵活性。
我看到的主要问题 hg pull --rebase是在没有任何撤消方法的情况下中断 merge 的能力。 DVCS 模型基于明确跟踪历史的想法，而 rebase 颠覆了这一想法，说我的所有更改都发生在您的所有更改之后，即使我们确实在同一时间处理它们。而且因为我不知道您的更改是什么(因为我的代码基于早期的更改集)，所以我很难知道我的代码在您的代码之上不会破坏某些内容。您还可以通过 rebase 失去分支功能，这实际上是 DVCS 背后的全部思想。
我们的工作流程(我们围绕它构建了一个 entire Mercurial hosting system)基于保留多个克隆或分支存储库，我们称之为。每个开发或小团队都有自己的分支存储库，它只是“中央”存储库的克隆。我所有的新功能和大型错误修复都进入了我的个人分支存储库。我可以对该代码进行同行评审，一旦认为准备就绪，我就可以将其 merge 到中央存储库中。
这给了我一些不错的好处。首先，我不会破坏构建，因为我的所有更改都在他们自己的存储库中，直到它们“准备就绪”。其次，如果我需要做一个单独的功能，或者我有一些更长时间运行的东西，比如下一个主要版本，我可以制作另一个分支存储库。第三，如果有需要快速修复的错误，我可以轻松地更改中央存储库。
也就是说，您可以通过多种不同的方式使用此工作流程。最简单的，也是我一开始的，就是保持单独的克隆。所以我会有 website-central , website-tghw等。它运行良好，特别是因为您可以在它们之间进行本地推拉。最近，我开始使用 remotebranches 在同一个 repo 中保留多个头。扩展以帮助管理它们和 hg nudge避免同时插入所有事情。
当然，有些人不太喜欢这个工作流程，通常是因为他们的 Mercurial 服务器很难制作服务器端克隆。在这种情况下，您也可以查看使用 named branches以帮助保持您的功能。不幸的是，它们不像 Git 分支那么灵活(这就是我们更喜欢分支存储库的原因)，但是一旦您了解如何关闭分支，以及为什么一旦开始一个分支就无法真正摆脱它们，它们就可以很好地工作。
这有点长，所以我将通过鼓励您接受 Mercurial 提供的高级分支和 merge (通过 SVN)来结束它。肯定有一个学习曲线，但是一旦掌握了它，它确实会让事情变得更容易。
关于Mercurial:使用 hg pull --rebase 的具体问题示例，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3759227/