主干:在敏捷的每一个冲刺阶段结束后，我们会推出一个部分可交付的产品。这些释放物被保存在后备箱里。

分支:每个正在进行的冲刺的所有并行开发代码都保存在分支中。

标签:每次我们发布一个部分可发货的产品的测试版，我们都会为它做一个标签。这为我们提供了在那个时间点可用的代码，允许我们在开发过程中的某个时间点需要时回到那个状态。

主干:在敏捷的每一个冲刺阶段结束后，我们会推出一个部分可交付的产品。这些释放物被保存在后备箱里。

分支:每个正在进行的冲刺的所有并行开发代码都保存在分支中。

标签:每次我们发布一个部分可发货的产品的测试版，我们都会为它做一个标签。这为我们提供了在那个时间点可用的代码，允许我们在开发过程中的某个时间点需要时回到那个状态。

在SVN中，标记和分支非常相似。

标签=在时间上定义的片段，通常用于发布

分支=在开发过程中定义的片段，通常用于1.0、1.5、2.0等主要版本，然后在发布时标记分支。这允许您继续支持产品版本，同时在主干中进行突破性的更改

Trunk =开发工作空间，这是所有开发应该发生的地方，然后从分支发布合并回来的更改。

我认为一些混淆来自标记概念和SVN中的实现之间的差异。对于SVN来说，标签是一个分支，它是一个副本。修改标签被认为是错误的，事实上，像TortoiseSVN这样的工具会警告你，如果你试图用../tags/..在路上。

这就是关于软件开发的事情，没有一致的知识，每个人似乎都有自己的方式，但这是因为它是一个相对年轻的学科。

这是我简单的方法，

trunk - trunk目录包含最新的、已批准的和合并的工作主体。与许多人所承认的相反，我的箱子只用于干净、整洁、合格的工作，而不是一个开发区域，而是一个释放区域。

在某个给定的时间点上，当主干似乎已经准备好释放时，它就会被标记并释放。

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

例如:我可以有一个迭代-5分支用于产品的第5轮开发，可能有一个原型-9分支用于第9轮实验，等等。

tags—标签目录包含已批准的分支和中继发布的快照。每当一个分支被批准合并到主干中，或者一个发布是由主干组成的，一个被批准的分支或主干发布的快照就会在标记下生成。

我想有了标签，我可以很容易地在时间里来回跳转到感兴趣的点。

一般来说(工具不可知的观点)，分支是用于并行开发的机制。一个SCM可以有0到n个分支。Subversion是0。

Trunk is a main branch recommended by Subversion, but you are in no way forced to create it. You could call it 'main' or 'releases', or not have one at all! Branch represents a development effort. It should never be named after a resource (like 'vonc_branch') but after: a purpose 'myProject_dev' or 'myProject_Merge' a release perimeter 'myProjetc1.0_dev'or myProject2.3_Merge' or 'myProject6..2_Patch1'... Tag is a snapshot of files in order to easily get back to that state. The problem is that tag and branch is the same in Subversion. And I would definitely recommend the paranoid approach: 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.

标签是最终的。其内容不应改变。从来没有。永远。你忘了发行通知里的一行字?创建一个新标记。淘汰或删除旧的。

现在，我读了很多关于“在某某分支中合并某某，然后最终在主干分支中合并”的内容。 这就是所谓的合并工作流，这里没有强制性的内容。这并不是因为你有一个主干分支，你必须合并回任何东西。

按照惯例，主干分支可以代表您的开发的当前状态，但这是一个简单的顺序项目，该项目具有:

没有“预先”开发(用于准备下一个下一个版本，这意味着这些更改与当前的“主干”开发不兼容) 没有大规模的重构(用于测试新的技术选择) 没有以前版本的长期维护

因为对于这些场景中的一个(或所有)，你会得到四个“主干”，四个“当前开发”，而不是你在这些并行开发中所做的所有事情都必须合并回“主干”中。