我已经在Subversion（我猜通用存储库）讨论中看到了很多这样的话。在过去的几年里，我一直在为我的项目使用SVN，但我从未掌握过这些目录的完整概念。
他们的意思是什么？
嗯，不确定我同意Nick重新标记类似于分支。标签只是一个标记
在开源项目中，项目利益相关者不接受进入主干的主要分支可以成为分支的基础 - 例如，与其他源代码共享共同起源的完全独立的项目。
分支和标记子树在以下方面与主干区分开来：
Subversion允许系统管理员创建钩子脚本，这些脚本在某些事件发生时被触发执行;例如，将更改提交到存储库。对于典型的Subversion存储库实现来说，在创建之后将包含“/ tag /”的任何路径视为写保护是很常见的;最终结果是标签一旦创建，就是不可变的（至少是“普通”用户）。这是通过钩子脚本完成的，如果tag是更改对象的父节点，则通过阻止进一步更改来强制执行不变性。
从版本1.5开始，Subversion还增加了与“分支合并跟踪”相关的功能，以便提交给分支的更改可以合并回主干，并支持增量的“智能”合并。
trunk目录是您可能最熟悉的目录，因为它用于保存最新的更改。您的主代码库应该在trunk中。
分支目录用于保存您的分支，无论它们是什么。
tags目录基本上用于标记某组文件。你可以在发布版本中执行此操作，在这些修订版中你希望“1.0”是这些文件，在这些版本中你想要“1.1”这些文件。您通常不会在制作标签后对其进行修改。有关标签的更多信息，请参阅Chapter 4. Branching and Merging（在Version Control with Subversion中）。
每个人定义略有不同的原因之一是因为Subversion对分支和标签实现零支持。 Subversion基本上说：我们在其他系统中查看了功能齐全的分支和标签，并没有发现它们有用，所以我们没有实现任何功能。只需使用名称约定复制到新目录中即可。当然，每个人都可以自由地拥有略微不同的约定。要了解真实标签与纯粹复制+命名约定之间的区别，请参阅维基百科条目Subversion tags & branches。
Tag =定义的时间片，通常用于发布
我认为这通常意味着“标签”。但是在Subversion中：
它们实际上没有任何正式含义。文件夹是SVN的文件夹。
我发现相当混乱：一个对分支或标签一无所知的修订控制系统。从实现的角度来看，我认为Subversion创建“副本”的方式非常聪明，但我必须要知道它是我称之为leaky abstraction。
或许我刚刚使用CVS太久了。
我认为一些混淆来自于标签概念与SVN中的实现之间的区别。对于SVN，标签是一个分支，它是一个副本。修改标签被认为是错误的，事实上，如果您尝试使用路径中的../tags/ ..修改任何内容，TortoiseSVN等工具会发出警告。
我不确定'标签'是什么，但分支是一个相当常见的源控制概念。
基本上，分支是一种在不影响主干的情况下处理代码更改的方法。假设您要添加一个相当复杂的新功能。您希望能够在进行更改时签入更改，但在完成该功能之前，不要让它影响主干。
首先，你要创建一个分支。这基本上是您创建分支时的主干副本。然后，您将在分支机构中完成所有工作。在分支中进行的任何更改都不会影响主干，因此主干仍然可用，允许其他人继续在那里工作（如做错误修正或小增强）。完成功能后，您将分支重新集成到主干中。这会将所有更改从分支移动到主干。
人们用于分支的模式有很多种。如果您的产品一次支持多个主要版本，通常每个版本都是一个分支。在我工作的地方，我们有一个QA分支和一个生产分支。在将代码发布到QA之前，我们将更改集成到QA分支，然后从那里进行部署。在发布到生产时，我们从QA分支集成到生产分支，因此我们知道生产中运行的代码与QA测试的代码相同。
这是Wikipedia entry on branches，因为他们可能比我能更好地解释事情。 :)
Trunk：在敏捷的每个冲刺完成后，我们推出了一个可部分发货的产品。这些版本保存在行李箱中。
分支机构：每个正在进行的冲刺的所有并行开发代码都保存在分支机构中。
标签：每次我们发布部分可交付的产品类型的测试版，我们都会为它制作一个标签。这为我们提供了那个时间点可用的代码，允许我们在开发期间的某个时刻返回该状态。
对于熟悉GIT的人来说，GIT中的master等同于SVN中的trunk。
分支和标记在GIT和SVN中具有相同的术语。
首先，正如@AndrewFinnell和@KenLiu指出的那样，在SVN中，目录名称本身并不代表什么 - “主干，分支和标签”只是大多数存储库使用的常见约定。并非所有项目都使用所有目录（根本不使用“标签”），事实上，没有什么能阻止你将它们称为任何你想要的东西，尽管破坏惯例常常令人困惑。
我将描述分支和标记的最常见使用场景，并给出一个如何使用它们的示例场景。
例如，假设你开始一个新项目。你开始在“trunk”中工作，最终将作为1.0版本发布。
1.0.0完成后，将trunk分支到一个新的“1.0”分支，并创建一个“1.0.0”标记。现在继续研究最终将继续在后备箱中继续使用1.1。
您在代码中遇到一些错误，并在trunk中修复它们，然后将修复程序合并到1.0分支。您也可以执行相反的操作，并修复1.0分支中的错误，然后将它们合并回主干，但通常项目坚持单向合并以减少丢失某些内容的机会。有时一个bug只能在1.0中修复，因为它在1.1中已经过时了。这并不重要：您只想确保不使用1.0中修复的相同错误发布1.1。
一旦找到足够的错误（或者可能是一个关键错误），您就决定发布1.0.1版本。因此，您从1.0分支创建标记“1.0.1”，并释放代码。此时，trunk将包含1.1的内容，“1.0”分支包含1.0.1代码。下次将更新发布到1.0时，它将是1.0.2。
最终你几乎准备好发布1.1，但你想先做一个测试版。在这种情况下，您可能会执行“1.1”分支和“1.1beta1”标记。现在，关于什么是1.2（或者可能是2.0）的工作继续在trunk中继续工作，但是在1.1的分支上继续工作1.1。
一旦你发布了1.1 final，你就可以从“1.1”分支中做一个“1.1”标记。
如果您愿意，还可以继续维护1.0，在所有三个分支（1.0,1.1和trunk）之间移植错误。重要的是，对于您正在维护的软件的每个主要版本，您都有一个分支，其中包含该版本的最新版本代码。
分支的另一个用途是用于特征。这是您分支主干（或您的一个发布分支）并单独处理新功能的地方。功能完成后，将其重新合并并删除分支。
这样做的想法是，当你正在研究破坏性的东西（会阻止或干扰其他人做他们的工作），实验性的东西（甚至可能没有它），或者可能只是需要很长时间的东西（当你准备好从主干分支1.2时，你担心如果它支持1.2版本），你可以在分支机构中单独进行。通常，您可以通过将更改合并到主干来使其保持最新状态，这样可以在完成后更轻松地重新集成（合并回主干）。
另请注意，我在这里使用的版本控制方案只是其中之一。有些团队会将错误修复/维护版本发布为1.1,1.2等，主要更改为1.x，2.x等。此处的用法相同，但您可以将分支命名为“1”或“1” .x“而不是”1.0“或”1.0.x“。 （另外，semantic versioning是如何做版本号的好指南）。
除了Nick所说的，你还可以在Streamed Lines: Branching Patterns for Parallel Software Development找到更多信息
在这个图中main是树干，rel1-maint是一个分支，1.0是一个标签。
通常（工具不可知视图），分支是用于并行开发的机制。 SCM可以具有0到n个分支。 Subversion有0。
标签是最终的。它的内容永远不会改变。决不。永远。你在发行说明中忘了一行？创建一个新标签。废弃或删除旧的。
现在，我读了很多关于“在这样的分支中合并这样的东西，然后最终在主干分支中”。这称为合并工作流程，这里没有强制要求。这不是因为你有一个主干分支，你必须合并回任何东西。
按照惯例，trunk分支可以表示开发的当前状态，但这是一个简单的顺序项目，即具有以下项目的项目：
因为有了这些场景中的一个（或全部），你会得到四个“中继”，四个“当前的发展”，并不是你在那些并行开发中所做的一切都必须在“主干”中合并。
在SVN中，标签和分支非常相似。
Tag =定义的时间片，通常用于发布
Branch =也是一个定义的时间片，开发可以继续，通常用于主要版本，如1.0,1.5,2.0等，然后当你发布时标记分支。这使您可以继续支持生产版本，同时继续进行中断更改
Trunk =开发工作空间，这是所有开发应该发生的地方，然后更改从分支版本合并回来。
它们实际上没有任何正式含义。文件夹是SVN的文件夹。它们是组织项目的普遍接受的方式。
但就像我说的，对SVN来说，文件夹是一个文件夹。 branch，trunk和tag只是一个惯例。
我正在大量使用“复制”这个词。 SVN实际上并不在存储库中制作完整的东西副本。
主干是包含最新源代码和功能的开发线。它应该有最新的错误修复程序以及添加到项目中的最新功能。
分支通常用于远离主干（或其他开发线）做某些事情，否则会破坏构建。新功能通常构建在分支中，然后合并回主干。分支通常包含不一定被批准用于其分支的开发线的代码。例如，程序员可以尝试对分支中的某些内容进行优化，并且只有在优化满意后才会在开发行中合并。
标签是特定时间的存储库的快照。这些都不应该发展。它们通常用于获取发布到客户端的副本，以便您可以轻松访问客户端正在使用的内容。
这是一个非常好的存储库指南的链接：
维基百科中的文章也值得一读。
现在这就是软件开发的问题，对于任何事情都没有一致的知识，每个人似乎都有自己的方式，但这是因为无论如何它都是一个相对年轻的学科。
这是我简单明了的方法，
trunk - trunk目录包含最新，已批准和合并的工作主体。与许多人承认的相反，我的行李箱仅用于清洁，整洁，批准的工作，而不是开发区域，而是一个释放区域。
在某个给定的时间点，当主干似乎已准备好释放时，它会被标记并释放。
分支 - 分支目录包含实验和正在进行的工作。分支机构的工作停留在那里，直到被批准合并到主干。对我来说，这是完成所有工作的领域。
例如：我可以在产品的第五轮开发中使用iteration-5分支，也可以在第九轮实验中使用原型9分支，依此类推。
tags - tags目录包含已批准的分支和主干版本的快照。每当分支机构被批准合并到主干中，或者发布主干时，都会在标签下创建已批准的分支或主干版本的快照。
我想有标签，我可以很容易地来回穿过时间点兴趣点。
当我查找author 2计算机视觉应用程序设计手册的OpenCV网站时，我找到了关于SVN的这个很棒的教程，我想我应该分享。
他有一个关于如何使用SVN的教程以及短语“trunk”，“tag”和“branch”的含义。
直接从他的教程中引用：
您的团队当前正在使用的当前版本的软件项目通常位于名为trunk的目录下。随着项目的发展，开发人员更新版本修复错误，添加新功能）并在该目录下提交更改。
在任何给定的时间点，您可能希望冻结版本并捕获软件的快照，就像在开发的这个阶段一样。这通常对应于您的软件的官方版本，例如，您将提供给客户的版本。这些快照位于项目的tags目录下。
最后，在某些时候为您的软件创建新的开发线通常很有用。例如，当您希望测试替代实施时，您必须修改软件，但在决定是否采用新解决方案之前，您不希望将这些更改提交到主项目。然后，主要团队可以继续处理项目，而其他开发人员则可以使用原型。您可以将项目的这些新开发线放在名为branches的目录下。