在Subversion(我想是通用存储库)的讨论中，我经常看到这些词。
过去几年中，我一直在项目中使用SVN，但是我从未掌握过这些目录的完整概念。

他们的意思是什么？

解决方案

回答

在SVN中，标签和分支确实很相似。

Tag =定义的时间片，通常用于发布

分支=也是可以继续进行开发的时间片，通常用于1.0、1.5、2.0等主要版本，然后在发布时标记分支。这使我们可以继续支持生产版本，同时继续进行主干中的重大更改。

Trunk =开发工作空间，应在此处进行所有开发，然后将更改从分支版本中合并回去。

回答

它们实际上没有任何正式含义。文件夹是文件夹
到SVN。它们是组织项目的一种普遍接受的方式。

• 主干是我们保持开发主线的地方。分支文件夹是我们可以在其中创建分支的位置，在简短的帖子中很难解释。
• 分支是我们与干线分开进行的项目子集的副本。可能是针对可能无法进行任何实验的实验，也可能是针对下一个版本的实验，我们将在稳定后将其合并到主干中。
• 标签文件夹通常用于在发布检查点创建存储库的标签副本。

但是就像我说的那样，对于SVN，文件夹就是文件夹。 branch，trunk和tag只是一个约定。

我在自由地使用"复制"一词。 SVN实际上并未在存储库中制作事物的完整副本。

回答

主干目录是我们可能最熟悉的目录，因为它用于保存最新更改。主要代码库应该在主干中。

分支目录用于保存分支(无论分支如何)。

tags目录基本上是用于标记一组文件的。我们可以针对发行版等进行此操作，在这些版本中，我们希望" 1.0"成为这些文件，而在这些版本中，让" 1.1"成为这些文件。标记一旦制成，通常就不会对其进行修改。有关标签的更多信息，请参见第4章。分支和合并(在Subversion版本控制中)。

回答

我不太确定"标签"是什么，但是分支是一个相当普遍的源代码管理概念。

基本上，分支是一种在不影响主干的情况下对代码进行更改的方法。假设我们要添加一个相当复杂的新功能。我们希望能够在进行更改时签入更改，但不希望更改影响干线，直到我们完成该功能。

首先，我们将创建一个分支。基本上，这是我们创建分支时的主干副本。然后，我们将在分支机构中完成所有工作。在分支中所做的任何更改都不会影响中继，因此中继仍然可用，从而允许其他人继续在中继上工作(例如进行错误修复或者小的增强)。一旦完成功能，就可以将分支集成回主干。这会将所有更改从分支移动到主干。

人们在分支机构中使用了多种模式。如果产品同时支持多个主要版本，则通常每个版本都是一个分支。在我工作的地方，我们有一个质量检查部门和一个生产部门。在将代码发布到质量检查之前，我们将更改集成到质量检查分支，然后从那里进行部署。在发布到生产环境时，我们从QA分支集成到Production分支，因此我们知道生产中运行的代码与QA测试的代码相同。

这是分支机构上的Wikipedia条目，因为它们可能比我能更好地解释事情。 :)

回答

嗯，不确定我是否同意Nick re tag与分支相似。标签只是一个标记

• 从项目开始到现在，干线将是开发的主体。
• 分支将是从主干中某个点派生的代码副本，用于在保留主干中代码完整性的同时对代码进行重大更改。如果重大更改按计划进行，则通常会将它们合并回主干。
• 标签将是我们要保留的主干或者分支上的时间点。保留的两个主要原因是：这是软件的主要发行版(无论是alpha，beta，RC还是RTM)，或者这是在应用主干上的重大修订之前软件的最稳定点。

在开源项目中，项目利益相关者不接受主干的主要分支可以成为分支的基础-例如，与其他源代码共享共同起源的完全独立的项目。

回答

主干是包含最新源代码和功能的开发线。它应该具有最新的错误修复以及添加到项目中的最新功能。

分支通常用于做一些远离主干(或者其他开发线)的事情，否则将破坏构建。新功能通常建在分支中，然后合并回主干。分支通常包含未必为其分支开发线批准的代码。例如，程序员可以对分支中的某些内容进行优化，并且只有在优化令人满意的情况下，才可以合并到开发线中。

标签是特定时间存储库的快照。在这些方面不应该发展。它们最常用于复制发布给客户端的内容，以便我们可以轻松访问客户端使用的内容。

这是一个非常好的存储库指南的链接：

• 源代码控制方法

维基百科中的文章也值得一读。

回答

除了Nick所说的之外，我们还可以在Streamed Lines：并行软件开发的分支模式中找到更多信息。

在此图中，" main"是主干，" rel1-maint"是分支，而" 1.0"是标签。

回答

我认为某些混淆来自标签概念和SVN中实现之间的差异。对于SVN，标签是一个分支，即一个副本。修改标签被认为是错误的，实际上，如果我们尝试在路径中使用../tags/ ..进行修改，则诸如TortoiseSVN之类的工具会警告我们。

回答

Tag = a defined slice in time, usually used for releases

我认为这通常是"标签"的意思。但是在Subversion中：

They don't really have any formal meaning. A folder is a folder to SVN.

我觉得这很令人困惑：一个对分支或者标签一无所知的版本控制系统。从实现的角度来看，我认为创建"副本"的Subversion方法非常聪明，但是我必须知道这就是所谓的泄漏抽象。

或者也许我刚刚使用CVS太久了。

回答

首先，正如@AndrewFinnell和@KenLiu指出的那样，在SVN中，目录名称本身没有任何意义-"主干，分支和标签"只是大多数存储库使用的通用约定。并非所有项目都使用所有目录(完全不使用"标签"是很普遍的做法)，事实上，尽管违反约定通常会造成混乱，但没有什么阻止我们调用它们。

我将描述分支和标签的最常见使用场景，并给出如何使用它们的示例场景。

• 主干：主要开发区域。这是下一个主要代码版本的所在地，通常具有所有最新功能。
• 分支：每次发布主要版本时，都会创建一个分支。这使我们可以进行错误修复并发布新版本，而不必发布最新的功能(可能尚未完成或者未经测试)。
• 标记：每次发布版本(最终发行版，候选发布版(RC)和Beta版)时，我们都会为其标记。这为我们提供了当时状态下的代码的时间点副本，允许我们在必要的情况下返回并重现任何错误，或者在以前的版本中完全重新发布。 SVN中的分支和标记是轻量级的-在服务器上，它不制作文件的完整副本，只是一个标记说"这些文件是在此修订版中复制的"，仅占用几个字节。考虑到这一点，我们永远不必担心为任何已发布的代码创建标签。如我之前所说，标记通常被省略，取而代之的是，发布版本时，变更日志或者其他文档阐明了修订版本号。

例如，假设我们开始一个新项目。我们将开始在" trunk"中工作，最终将以1.0版发布。

• trunk /-开发版本，即将发布1.0
• 分支机构/-空

1.0.0完成后，将中继分支到新的" 1.0"分支中，并创建" 1.0.0"标签。现在，关于最终将是1.1的工作将继续在主干中进行。

• trunk /-开发版本，即将发布1.1
• branchs / 1.0-1.0.0发行版本
• 标签/1.0.0-1.0.0发行版本

我们会在代码中遇到一些错误，并在主干中对其进行修复，然后将这些修复程序合并到1.0分支中。我们也可以执行相反的操作，并修复1.0分支中的错误，然后将其合并回主干，但是通常项目坚持单向合并，以减少丢失某些内容的机会。有时，错误只能在1.0中修复，因为它在1.1中已过时。其实并不重要：我们只想确保我们不会发布与1.0中已修复的相同错误的1.1.

• trunk /-开发版本，即将发布1.1
• 分支机构/1.0-即将发布的1.0.1版本
• 标签/1.0.0-1.0.0发行版本

一旦发现足够的错误(或者可能是一个严重的错误)，便决定执行1.0.1版本。因此，我们可以从1.0分支中创建一个标记" 1.0.1"，然后释放代码。此时，主干将包含1.1，而" 1.0"分支包含1.0.1代码。下次我们发布对1.0的更新时，它将是1.0.2.

• trunk /-开发版本，即将发布1.1
• 分支机构/1.0-即将发布的1.0.2版本
• 标签/1.0.0-1.0.0发行版本
• 标签/1.0.1-1.0.1发行版本

最终，我们几乎已经准备好发布1.1，但是我们想先进行Beta测试。在这种情况下，我们可能会执行" 1.1"分支和" 1.1beta1"标记。现在，将在主干中继续进行关于1.2(或者2.0)的工作，而在" 1.1"分支中继续进行关于1.1的工作。

• trunk /-开发版本，即将发布1.2
• 分支机构/1.0-即将发布的1.0.2版本
• 分支机构/1.1-即将发布的1.1.0版本
• 标签/1.0.0-1.0.0发行版本
• 标签/1.0.1-1.0.1发行版本
• 标签/1.1beta1-1.1 beta 1发行版本

一旦发布了1.1最终版，就可以从" 1.1"分支中执行" 1.1"标签。

如果愿意，还可以继续维护1.0，在所有三个分支(1.0、1.1和trunk)之间移植bug修复程序。重要的一点是，对于要维护的软件的每个主要版本，我们都有一个分支，其中包含该版本的最新代码。

分支的另一种用途是用于功能。在这里，我们可以分支干线(或者其中一个发布分支)，并单独开发新功能。功能完成后，将其合并回去并删除分支。

• trunk /-开发版本，即将发布1.2
• 分支机构/1.1-即将发布的1.1.0版本
• 分支/ ui重写-实验功能分支

这样的想法是，当我们正在从事破坏性工作(可能阻碍或者干扰他人的工作)，正在尝试性工作(甚至可能无法完成工作)或者可能只需要很长时间时(而且，当我们准备从主干分支1.2时，如果担心它支撑着1.2版本)，我们可以在分支中单独进行操作。通常，我们可以通过始终将更改合并到主干中来使其保持最新状态，从而在完成后更易于重新集成(合并回主干)。

还要注意，我在这里使用的版本控制方案只是众多方案之一。有些团队会进行1.1 / 1.2等错误修复/维护，而对1.x，2.x等进行主要更改。这里的用法相同，但是我们可以将分支命名为" 1"或者" 1 .x"，而不是" 1.0"或者" 1.0.x"。 (此外，语义版本控制是有关如何执行版本号的良好指南)。

回答

通常，(与工具无关的视图)分支是用于并行开发的机制。一个SCM可以有0到n个分支。 Subversion有0。

• Trunk是Subversion推荐的主要分支，但绝不强迫我们创建它。我们可以将其称为"主要"或者"发布"，也可以根本没有！
• 发布范围'myProjetc1.0_dev'或者myProject2.3_Merge'或者'myProject6..2_Patch1'...
• 标记是文件的快照，以便轻松返回到该状态。问题在于Subversion中的标签和分支是相同的。我绝对会推荐偏执的方法：

you can use one of the access control scripts provided with Subversion to prevent anyone from doing anything but creating new copies in the tags area.

标签是最终的。它的内容永远都不会改变。绝不。曾经。我们忘了发行说明中的​​一行吗？创建一个新标签。过时或者删除旧的。

现在，我读了很多有关"将这样的分支合并到这样的分支中，然后最终合并到主干分支中"的文章。
这称为合并工作流，这里没有强制要求。并不是因为我们有主干分支，所以我们必须合并任何内容。

按照惯例，主干分支可以表示开发的当前状态，但这是针对简单的顺序项目的，即具有以下内容的项目：

• 没有"预先"开发(用于准备下一个下一个版本，暗示这些更改与当前的" trunk"开发不兼容)
• 无需大量重构(用于测试新的技术选择)
• 无需长期维护以前的版本

因为使用这些场景中的一个(或者全部)，我们将获得四个"主干"，四个"当前开发"，并且并非我们在这些并行开发中所做的所有工作都必须合并回"主干"。

回答

现在是关于软件开发的事情，对任何事情都没有统一的知识，每个人似乎都有自己的方式，但这是因为无论如何这是一门相对较年轻的学科。

这是我简单的方法，

主干主干目录包含最新的，批准的和合并的工作体。与许多人承认的相反，我的行李箱仅用于清洁，整洁，经过批准的工作，而不是用于开发区域，而是用于发布区域。

在某个特定的时间点，当中继线似乎都准备好释放时，便会对其进行标记和释放。

分支分支目录包含实验和正在进行的工作。分支机构下的工作会一直待在那里，直到被批准合并到主干中为止。对我来说，这是完成所有工作的区域。

例如：对于产品的第五轮开发，我可以有一个迭代5分支，对于第九轮实验，可以有一个原型9分支，依此类推。

标签标签目录包含批准的分支和主干版本的快照。每当批准分支合并到主干中或者发布主干时，都会在标签下创建批准的分支或者主干发布的快照。

我想有了标签，我可以很容易地在时间上来回跳动来指出兴趣点。

回答

每个人的定义稍有不同的原因之一是因为Subversion对分支和标签实现了零支持。 Subversion基本上说：我们查看了其他系统中功能齐全的分支和标签，但发现它们没有用，所以我们没有实现任何东西。只需将副本复制到具有名称约定的新目录中即可。那么，当然每个人都可以自由选择略有不同的约定。了解真实标签与纯拷贝+命名约定之间的区别
请参阅Wikipedia条目Subversion标记和分支。