现在，我读了很多关于"merging back such and such in such and such branches, then finally in the trunk branch"的内容 . 这叫 merge workflow ，有 nothing mandatory here . 这不是因为你有一个主干分支，你必须合并回任何东西 .
按照惯例，trunk分支可以表示开发的当前状态，但这是一个简单的顺序项目，即具有以下项目的项目：
no 'in advance'开发（用于准备下一个版本，意味着这些更改与当前的'trunk'开发不兼容）
16 回答
我认为这通常意味着“标签” . 但是在Subversion中：
我觉得相当混乱：一个对分支或标签一无所知的修订控制系统 . 从实现的角度来看，我认为创建"copies"的Subversion方式非常聪明，但我不得不知道它是我所谓的leaky abstraction .
或许我刚刚使用CVS太久了 .
trunk 是包含最新源代码和功能的开发行 . 它应该有最新的错误修复程序以及添加到项目中的最新功能 .
branches 通常用于远离主干（或其他开发线），否则会破坏构建 . 新功能通常构建在分支中，然后合并回主干 . 分支通常包含不一定被批准用于其分支的开发线的代码 . 例如，程序员可以尝试对分支中的某些内容进行优化，并且只有在优化满意后才会在开发行中合并 .
tags 是特定时间存储库的快照 . 这些都不应该发展 . 它们通常用于获取发布到客户端的副本，以便您可以轻松访问客户端正在使用的内容 .
这是一个非常好的存储库指南的链接：
维基百科的文章也值得一读 .
除了尼克所说的你还可以在Streamed Lines: Branching Patterns for Parallel Software Development找到更多信息 .
在这个图中
main是主干，rel1-maint是分支，1.0是标签 .In general （工具不可知视图），分支是用于并行开发的机制 . SCM可以具有0到n个分支 . Subversion有0 .
Trunk 是一个主分支recommended by Subversion，但您绝不会被迫创建它 . 你可以称之为'main'或'releases'，或者根本没有！
Branch 代表了一项开发工作 . 它永远不应该在资源（如'vonc_branch'）之后命名，但在之后：
目的'myProject_dev'或'myProject_Merge'
释放周长'myProjetc1.0_dev'或myProject2.3_Merge ' or ' myProject6..2_Patch1'...
Tag 是文件的快照，以便轻松返回到该状态 . The problem is that tag and branch is the same in Subversion . 我肯定会推荐偏执的方法：
标签是最终的 . 它的内容永远不会改变 . 决不 . 永远 . 你在发行说明中忘了一行？创建一个新标签 . 废弃或删除旧的 .
现在，我读了很多关于"merging back such and such in such and such branches, then finally in the trunk branch"的内容 . 这叫 merge workflow ，有 nothing mandatory here . 这不是因为你有一个主干分支，你必须合并回任何东西 .
按照惯例，trunk分支可以表示开发的当前状态，但这是一个简单的顺序项目，即具有以下项目的项目：
no 'in advance'开发（用于准备下一个版本，意味着这些更改与当前的'trunk'开发不兼容）
没有大规模的重构（用于测试新的技术选择）
没有长期维护以前的版本
因为有了这些场景中的一个（或全部），你会得到四个“中继”，四个“当前的发展”，而不是你在那些并行开发中所做的一切都必须在“主干”中合并 .
每个人定义略有不同的原因之一是因为Subversion实现了对分支和标签的 zero 支持 . Subversion基本上说：我们在其他系统中查看了功能齐全的分支和标签，并没有发现它们有用，所以我们没有实现任何东西 . 只需使用名称约定复制到新目录中即可 . 当然，每个人都可以自由地拥有略微不同的约定 . 要了解真实标记和仅仅复制命名约定之间的区别，请参阅Wikipedia条目Subversion tags & branches .
我认为一些混淆来自于标签概念与SVN中的实现之间的区别 . 对于SVN，标签是一个分支，它是一个副本 . 修改标签被认为是错误的，事实上像TortoiseSVN这样的工具会在你试图用路径中的../tags/ ..修改任何东西时发出警告 .
对于熟悉GIT的人来说，GIT中的master等同于SVN中的trunk .
分支和标签在GIT和SVN中具有相同的术语 .
现在这就是关于软件开发的事情，对于任何事情都没有一致的知识，每个人似乎都有自己的方式，但那是因为它无论如何都是一个相对年轻的学科 .
这是我简单明了的方法，
trunk - trunk目录包含最新，已批准和合并的工作主体 . 与许多人承认的相反，我的 Baggage 箱仅用于清洁，整洁，批准的工作，而不是开发区域，而是一个释放区域 .
在某个给定的时间点，当主干似乎已准备好释放时，它会被标记并释放 .
branches - branches目录包含实验和正在进行的工作 . 分支机构的工作停留在那里，直到被批准合并到主干 . 对我来说，这是完成所有工作的领域 .
例如：我可以在产品的第五轮开发中使用iteration-5分支，也可以在第九轮实验中使用原型9分支，依此类推 .
tags - tags目录包含已批准的分支和主干版本的快照 . 每当分支机构被批准合并到主干中，或者发布主干时，都会在标签下创建已批准的分支或主干版本的快照 .
我想，有了标签，我可以很快地来回穿过时间点兴趣点 .
在SVN中，标签和分支非常相似 .
Tag =定义的时间片，通常用于发布
Branch =也是一个定义的时间片，开发可以继续，通常用于主要版本，如1.0,1.5,2.0等，然后当你释放你标记分支 . 这个允许您继续支持 生产环境 版本，同时继续改进主干中的更改
Trunk =开发工作空间，这是所有开发应该发生的地方，然后更改从分支发布版本合并回来 .
当我查找OpenCV 2计算机视觉应用程序设计手册的author的网站时，我发现了关于SVN的这个很棒的教程，我想我应该分享 .
他有一个关于如何使用SVN的教程以及短语“trunk”，“tag”和“branch”的含义 .
直接从他的教程中引用：
嗯，不确定我同意Nick重新标记类似于分支 . 标签只是一个标记
Trunk将成为发展的主体，从项目的开始直到现在 .
Branch将是从主干中某个点派生的代码副本，用于对代码进行重大更改，同时保留主干中代码的完整性 . 如果主要变更按计划运作，它们通常会合并回主干 .
Tag将是您希望保留的主干或分支上的某个时间点 . 保存的两个主要原因是这是软件的主要版本，无论是alpha版，beta版，RC版还是RTM版，或者在应用主干修订版之前，这是软件中最稳定的一点 .
在开源项目中，项目利益相关者不接受主干的主要分支可以成为分支的基础 - 例如，与其他源代码共享共同起源的完全独立的项目 .
首先，正如@AndrewFinnell和@KenLiu指出的那样，在SVN中，目录名称本身没有任何意义 - “主干，分支和标签”只是大多数存储库使用的常见约定 . 并非所有项目都使用所有目录（根本不使用“标签”），事实上，没有什么能阻止你将它们称为任何你想要的东西，尽管违反常规通常会令人困惑 .
我将描述分支和标记的最常见使用场景，并给出一个如何使用它们的示例场景 .
Trunk ：主要开发区 . 这是您下一个主要版本的代码所在的位置，并且通常具有所有最新功能 .
Branches ：每次发布主要版本时，都会创建一个分支 . 这允许您进行错误修复并制作新版本，而无需发布最新的 - 可能未完成或未经测试的功能 .
Tags ：每次发布版本（最终版本，发布候选版本（RC）和beta版本）时，都会为其制作标记 . 这为您提供了该状态下代码的时间点副本，允许您在过去的版本中返回并重现任何错误，或者完全按照原样重新发布过去的版本 . SVN中的分支和标签是轻量级的 - 在服务器上，它不会生成文件的完整副本，只是一个标记"these files were copied at this revision"只占用几个字节的标记 . 考虑到这一点，您永远不应该担心为任何已发布的代码创建标记 . 正如我之前所说，标签经常被省略，相反，更新日志或其他文档在发布时澄清了修订号 .
例如，假设你开始一个新项目 . 你开始在“trunk”中工作，最终将作为1.0版本发布 .
trunk/ - development version, soon to be 1.0
branches / - 空
1.0.0完成后，将trunk分支到新的“1.0”分支，并创建一个“1.0.0”标记 . 现在继续研究最终将继续在主干中运行的1.1 .
trunk / - 开发版， soon to be 1.1
branches/1.0 - 1.0.0 release version
tags/1.0.0 - 1.0.0 release version
您在代码中遇到一些错误，并在trunk中修复它们，然后将修复程序合并到1.0分支 . 你也可以做相反的事情，并修复错误1.0分支然后将它们合并回主干，但通常项目坚持单向合并以减少丢失某些东西的机会 . 有时一个bug只能在1.0中修复，因为它在1.1中已经过时了 . 这并不重要：您只想确保不使用1.0中修复的相同错误发布1.1 .
trunk / - 开发版，很快就会是1.1
branches / 1.0 - upcoming 1.0.1 release
tags / 1.0.0 - 1.0.0发布版本
一旦找到足够的错误（或者可能是一个关键错误），您就决定发布1.0.1版本 . 因此，您从1.0分支创建标记“1.0.1”，并释放代码 . 此时，trunk将包含1.1的内容，“1.0”分支包含1.0.1代码 . 下次将更新发布到1.0时，它将是1.0.2 .
trunk / - 开发版，很快就会是1.1
branches / 1.0 - upcoming 1.0.2 release
tags / 1.0.0 - 1.0.0发布版本
tags/1.0.1 - 1.0.1 release version
最终你几乎准备好发布1.1，但你想先做一个测试版 . 在这种情况下，您可能会执行“1.1”分支和“1.1beta1”标记 . 现在，继续在trunk中继续工作1.2（或者可能是2.0），但在1.1的分支中继续工作1.1 .
trunk / - 开发版， soon to be 1.2
branches / 1.0 - 即将发布的1.0.2版本
branches/1.1 - upcoming 1.1.0 release
tags / 1.0.0 - 1.0.0发布版本
tags / 1.0.1 - 1.0.1发布版本
tags/1.1beta1 - 1.1 beta 1 release version
一旦你发布了1.1 final，你就会从“1.1”分支中做一个“1.1”标记 .
如果您愿意，还可以继续维护1.0，在所有三个分支（1.0,1.1和trunk）之间移植错误 . 重要的是，对于您正在维护的软件的每个主要版本，您都有一个分支，其中包含该版本的最新版本代码 .
分支的另一个用途是用于特征 . 这是您分支主干（或您的一个发布分支）并单独处理新功能的地方 . 功能完成后，将其重新合并并删除分支 .
trunk / - 开发版，很快就会是1.2
branches / 1.1 - 即将发布的1.1.0版本
branches/ui-rewrite - experimental feature branch
这样做的想法是当你在破坏性的东西（这会阻碍或干扰其他人做他们的工作），实验性的东西（甚至可能没有它），或者可能只需要很长时间的东西（当你准备从主干分支1.2时，你担心如果它支持1.2版本），你可以在分支机构中单独进行 . 通常，您可以通过将更改合并到主干来使其保持最新状态，这样可以在完成后更轻松地重新集成（合并回主干） .
另请注意，我在这里使用的版本控制方案只是其中之一 . 有些团队会将错误修复/维护版本修改为1.1,1.2等，主要更改为1.x，2.x等 . 此处的用法相同，但您可以将分支命名为"1"或"1.x"而不是"1.0"或"1.0.x" . （旁白，semantic versioning是如何做版本号的好指南） .
trunk目录是您可能最熟悉的目录，因为它用于保存最新的更改 . 您的主代码库应该在trunk中 .
分支目录用于保存您的分支，无论它们是什么 .
tags目录主要用于标记某组文件 . 你可以在需要"1.0"的版本中执行此操作这些修订版中的这些文件和"1.1"是这些修订版中的这些文件 . 你通常不会做出来 . 有关标签的更多信息，请参阅Chapter 4. Branching and Merging（在Version Control with Subversion中） .
我不太确定'标签'是什么，但分支是一个相当常见的源控制概念 .
基本上，分支是一种在不影响主干的情况下处理代码更改的方法 . 假设您要添加一个相当复杂的新功能 . 您希望能够在进行更改时检入更改，但在完成该功能之前，不要让它影响主干 .
首先，你要创建一个分支 . 这基本上是您创建分支时的主干副本 . 然后，您将在分支机构中完成所有工作 . 在分支中进行的任何更改都不会影响主干，因此主干仍然可用，允许其他人继续在那里工作（如做错误修正或小增强） . 完成功能后，您将分支重新集成到主干中 . 这会将所有更改从分支移动到主干 .
人们用于分支的模式有很多种 . 如果您同时支持多个主要版本的产品，通常每个版本都是一个分支 . 在我工作的地方，我们有一个QA分支和一个 生产环境 分支 . 在将代码发布到QA之前，我们将更改集成到QA分支，然后从那里进行部署 . 在发布到 生产环境 时，我们从QA分支集成到 生产环境 分支，因此我们知道 生产环境 中运行的代码与QA测试的代码相同 .
这是Wikipedia entry on branches，因为他们可能比我能更好地解释事情 . :)
Trunk ：在每个敏捷冲刺完成后，我们推出了一款可部分发货的产品 . 这些版本保存在 Baggage 箱中 .
Branches ：每个正在进行的冲刺的所有并行开发代码都保存在分支中 .
Tags ：每当我们发布部分可交付产品的测试版时，我们都会为它制作一个标签 . 这为我们提供了那个时间点可用的代码，允许我们在开发期间的某个时刻返回该状态 .
它们实际上没有任何正式含义 . 文件夹是SVN的文件夹 . 它们是组织项目的普遍接受的方式 .
Baggage 箱是您保持主要发展方向的地方 . 您可以在分支文件夹中创建分支文件，这些文章很难在短文中解释 .
分支是项目子集的副本，您可以与主干分开处理 . 也许是因为实验可能不会发生在任何地方，或者可能是下一个版本，当它变得稳定时你将稍后合并回主干 .
tags文件夹用于创建存储库的标记副本，通常是在发布检查点 .
但就像我说的那样，对于SVN来说，文件夹就是一个文件夹 .
branch，trunk和tag只是一种约定 .我正在大量使用“复制”这个词 . SVN实际上并不在存储库中制作完整的东西副本 .