如何将库的不同版本置于版本控制之下？您是否使用标签？还是分支机构？还是其他方法？

我最近开始将代码置于版本控制下（在实验室中，我正在SVN下工作，而我自己的代码在github中（显然是git））。在使用版本控制之前，我曾经做过类似的事情。我有一个带库名称的文件夹，其中有许多带版本号的文件夹。每当我想开始使用新版本时，我都会复制上一个版本，将名称更改为新版本并开始实施。

但是，当将文件夹置于版本控制下时，这似乎是多余的。除了冗余之外，如果有人想获得最新版本，那么只要他import/ 她就可以下载所有版本clone。

现在，我看到了使用版本控制执行此操作的许多方法，但是由于我是新手，所以我不知道哪种方法更可维护。

方法1：使用标签

如果我正确地理解了标签，那么您将拥有主分支，您可以进行所做的任何更改并使用版本进行标签。然后，当您想要获得它的工作副本时，您将获得带有特定标签的副本。（如果我错了纠正我）

方法2：分支版本

在这种方法中，主要分支将是开发分支。时不时地制作一个稳定的版本（例如v1.2.0），您为该版本创建一个分支，并且永远不要提交它。这样，如果您要下载某个版本，则可以从该分支获取代码。尽管我说过您从未承诺过这样做，但有可能进行错误修复并承诺到旧版本的分支以保持旧版本运行。例如，如果当前版本为v2.0，但是有些人想要使用v1.2，则可以从中获取另一个分支v1.2，即v1.2.1提交错误修复程序，或者仅将版本保持不变，v1.2然后提交错误修复程序。

所以分支看起来像这样：

                  v1.2.1  v1.2.2
                 /       /
 v1.0.0   v1.2.0---------     v2.0.0
/        /                   /
-------------------------------------- dev

这样，您可以为每个次要版本更新创建分支。（请注意，在上图中，v1.2.1和v1.2.2或在v2.0.0发布之后创建的，因此它们不是v1.2.0和v2.0.0之间的开发的一部分。可以将其视为对较早版本的支持）

方法3：分支发展

此方法与以前的方法相反。主分支将是最新的稳定版本。每当使用新版本时，都将创建一个分支（用于开发），使用您的代码，并在代码稳定后将其与主分支合并。

在这种情况下，分支看起来像这样：

 ________  ____  ________________  _____ dev
/        \/    \/                \/
---------------------------------- latest_version

可能需要结合标签一起执行此操作吧？

问题！

无论如何，我的问题是，根据您的经验，这些方法中的哪一种被证明更实用？有没有已知的最佳方法（可能我没有弄清楚自己）？这些事情通常是怎么做的？

标签和分支不是相互的，您可以（而且IMO通常应该）同时使用它们。标签在那里标记着发展的里程碑。例如，你打开你的产品的1.2版中的分支，你标记v1.2 Beta，RC1，RC2，Final（然后，如果需要的话，SP1等）对同一分支标签。

我个人更喜欢方法2作为默认方法（尽管我尝试避免分支的多个层次，以使生活尽可能简单）。方法1只是在现实生活中行不通-标签还不够，您需要分支。方法3不灵活，因为它始终都只有一个稳定版本，因此（除非您将其与方法2结合使用），您不能并行维护多个（最新和较旧）版本。这对于现实生活中的几乎所有项目都是必需的-在使用版本2时，您仍然应该能够发布v1.9的补丁程序/升级版，甚至通常是更早的版本。当然，很大程度上取决于应用程序的类型。我们开发了一个网络应用，因此在任何给定的时间点只有一个生产版本，但我们经常会尝试使用3个不同的版本（一个在生产中，一种是准备部署的UAT，一种是主干上的最新版本。对于同时使用和维护多个较旧版本的桌面/客户端应用程序，它可能变得更加复杂。

我有一个带库名称的文件夹，其中有许多带版本号的文件夹。

如您所注意到的，这实际上是一种错误的方法，因为您已经具有版本控制来控制版本。

现在，您列举的不同技术似乎同样正确。您可以阅读非常详细的文章Source Control Done Right，其中包含有关标签和分支的信息。

三种方法不是互斥的，您应该结合使用三种方法以充分利用版本控制。

就我而言，默认情况下，我将使用方法1和3的组合，即在功能部件或开发分支中进行开发，直到功能部件可以投入生产，然后再合并回主干。这样，Trunk始终代表着稳定，待用开发的当前状态，并且可以通过svn：external项目安全地链接。发布版本时，请对其进行标记。

我只是想上的需求，即，当旧版本库的有一个bug分支已经是固定的。您可以根据残破版本的标签轻松创建该分支。通过避免不必要的分支，可以减少分支的数量，并快速概览需要维护的出血边缘（树干和所有分支）。

我将使用方法2。我使用了它，发现它是管理和维护多个版本的有效方法，同时仍允许当前的开发向前发展。如果需要，也可以将标签与此方法结合使用。

有关使用分支维护多个发行版的更多信息，请参见此处的答案。