问作为一个单独的开发人员，我应该如何使用Mercurial？

EN

我使用Mercurial开发FsCheck，这是一个托管在codeplex中的单元测试框架。我目前是唯一的开发人员，但偶尔会有人给我发补丁。

具体地说，我的文件系统中有一个名为"FsCheck“的文件夹。其中，我有一个存储库，也就是文件夹，名为main。通常，我在它旁边有几个文件夹，在那里我处理特定的功能或bug修复或其他任何东西，比如bug转义异常和feat-statefulchecking和patch-userFoo。这些是使用hg克隆创建的。

当我完成一个特性或错误修复后，我提交该文件夹中的所有内容并推送到main。可能在main中合并。(hg提交，hg推送，hg合并)。然后我删除文件夹(小心使用hg状态和hg输出，以确保我没有丢弃一些有用的东西)。

我几乎从来没有在main中工作过，除非是在发布之前，在那里我会做最后的清理(比如文档)。在发布之前，我在main中使用版本号进行标记(hg tag v0.5.1)。

Codeplex使用svn作为源控制。我只使用它来存储发布，对于发布，我使用本地签出的SVN工作副本，我使用hg存档将Mercurial存储库复制到其中。然后使用svn提交。原始的，但它是有效的(在我的操作中，使用Mercurial作为windows上的SVN‘超级客户端’还不是很友好)

我还没有在以前的版本上进行维护，但我会通过从该版本的修订版克隆主存储库(这很容易，因为我对其进行了标记)，并在该单独的存储库中工作。合并回主干就像将更改推送到主干并合并一样简单。

总而言之：

• 一个文件夹，用于存储项目的所有存储库，项目
• 的名称位于该文件夹中。一个主存储库，每个“工作单元”一个临时存储库，以及工作单元的描述性名称。

这很好，因为您的分支和正在处理的内容在文件系统中是直观可见的。

从你的问题的表达方式来看，我认为你可能对版本控制术语有一些误解。

每个项目都应该有一个单独的存储库。您可以简单地将存储库视为文件系统上的一个文件夹。初始化特定文件夹中的Mercurial存储库时，该文件夹及其任何子文件夹中的每个文件都有资格被添加到存储库，以进行版本控制。您不一定要添加所有内容，但只要您愿意，就可以添加任何内容。

如果愿意，您可以将此本地存储库推送到远程存储库，作为一种备份形式或与他人共享代码的一种方法。但如果这只是一个简单的个人项目，这很可能是没有必要的，特别是因为你已经有了一个备份解决方案。

分支通常用于将项目的不同“版本”分开。正如一些人所提到的，作为一个单独的开发人员，这对于尝试重构代码的方法，或者测试解决特定问题的不同方法是很有用的。如果它不工作，您不必担心找出回滚到哪里，您只需烧了分支。如果它确实起作用了，你就把分支合并回主库(“主干”)，然后继续。

如果您确实需要对代码进行“发布”，并且需要继续维护旧版本，那么您也会希望使用分支。例如，假设您发布了1.0版，一些人开始使用它。当他们使用它的时候，你私下继续工作到下一个版本，可能是1.1，在你的主干存储库中添加功能。现在，有人在发布的1.0代码中发现了一个您需要修复的bug，但您不能只在主干中修复它，然后将代码提供给他们，因为它处于无法发布的状态。这就是1.0分支派上用场的地方。您可以修复1.0分支中的bug，并将bugfix更改合并到主干中，这样bug也会在那里得到修复。然后，您可以使用bugfix重新打包1.0版，并将其发布给您的用户，而不必考虑如何将主干转换为可以向公众发布的状态。

除此之外，使用Mercurial solo通常不会涉及太多花哨的工作。做一些工作，当你完成一个特性时，提交它来给你自己一个“检查点”，如果需要的话，你可以在将来回来。你不需要在每次保存或类似的事情时都提交，只要你觉得你添加了一些有意义的东西就行了。如果你需要回顾这个项目，这将给你一个很好的项目历史。

要了解更多信息，我强烈建议花点时间通读这本书：Distributed revision control with Mercurial。你不必阅读高级主题，但至少阅读第1-5章和第8章会给你一个很好的介绍Mercurial和版本控制的一般知识。

我使用了另一个分布式版本控制系统，而不是Mercurial，但我怀疑它对此很重要。

在我的个人项目中，我使用了相当多的分支。我通常有一个主要的开发分支(“主干”)，它应该在任何时候都有一个工作版本。我的意思是单元测试和其他自动化测试通过，所有代码都由这些测试测试，除了我从测试覆盖范围中明确排除的一小部分代码。这确保了主干始终处于良好的状态，以便进一步开发。

每当我开始处理更改时，我都会在主干分支上创建一个新分支。这给了我自由破解的自由。例如，我可能不担心自动测试通过这个分支。因为它是一个孤立的区域，我可以随心所欲地提交，我确实做到了:微提交是我最喜欢的分布式版本控制功能。当分支中的工作完成后，我将其合并回主干。

这种工作方式的好处是，如果事实证明我正在进行的更改是一个糟糕的想法，我可以很容易地退出。事实上，没有什么可退缩的，因为更改还没有合并。

有时我很懒，不会为我正在开发的新东西创建新的分支。当我需要比预期更多的时间来完成工作时，事实总是证明这是一个错误。当我需要在这个过程中做另一个无关的更改时，情况会变得更糟。当我遵循all-work- in - done branch风格时，不相关的更改可以在它自己的分支中完成，合并到主干中，然后其他分支可以合并来自主干的更改，如果需要的话。