树干，分支，标签和相关概念

Trunk，Branch和Tag概念与修订控制 （或版本控制 ）系统有关。 这些系统通常实现为包含电子文档以及这些文档的更改的存储库 。 对文档的每组更改都标记有修订 （或版本 ） 号 。 这些数字唯一地标识每组修改。

提醒

诸如Subversion之类的版本控制系统可与中央存储库一起使用。 用户可以将其内容（即文档） 签到本地PC。 他们可以在本地对这些文档进行修改。 然后，用户可以
将其更改提交回存储库。

如果不同用户同时提交对文档的修改之间存在冲突，则Subversion将要求每个用户先在本地解决冲突，然后再将他们的修改接受回存储库。 这确保了对存储库内容进行的每个修订 （即，修改集）之间的连续性。

这有什么用？ 如果使用存储库来存储软件开发代码文件，则每个开发人员都可以在本地检出这些文件，并且在进行修改后，他们可以确保将这些文件正确编译，然后再将其修改提交回存储库。 这样可以保证每个修订版都能正确编译，并且代码不包含任何不连贯性。

树干，树枝和标签

有时，软件开发需要处理大量代码。 这也可以是实验代码。 可能涉及多个软件开发人员。 这些修改太大，以至于可能需要拥有存储库内容的临时副本以进行处理，而不修改原始内容。 此问题已通过主干和分支解决。

使用Subversion时，存储库中的典型目录结构由三个目录组成：主干，分支和标签。 主干包含开发的主线。 为了解决上述问题，可以创建一个分支。 该分支是给定修订版本号的主开发线（主干）的副本。

软件开发人员可以像使用中继内容一样签出分支。 他们可以在本地执行修改，然后将内容提交回分支。 中继内容不会被修改。 多个软件开发人员可以像在主干上一样在此分支上工作。

一旦对分支进行了所有修改（或批准了实验代码），就可以将这些修改合并回主干。 就像简单的签出一样，如果存在任何不一致性，Subversion将要求软件开发人员在分支级别解决问题，然后再接受将分支合并回主干。

分支合并后，它也将关闭。 不再接受对其的修改。 可以从中继同时创建多个分支。 分支也可以被放弃和删除。 修改不会合并回主干。

当软件开发团队完成了一个项目，并且所有修改都已提交或合并回主干后，您可能想要从主干中释放代码的副本（或快照 ）。 这称为标签。 代码被复制到标签目录内的目录中。 通常，将发行版的版本用作目录名（例如
1.0.0）。

与分支相反，标签并不意味着要接受进一步的修改。 只能在主干和分支上执行进一步的修改。 如果发布的标签需要修改，则应创建标签的分支（而不是主干）（例如，名称为1.0.x）。 以后，可以使用次要发行版（例如1.0.1）创建该标签分支中的其他标签。

为什么这样工作？ 想象一下，一个软件应用程序已发布并投入生产（版本1.0.0）。 该团队从主干（或从主干的分支）进行版本2.0.0的工作。 这对于代码行的连续性是有意义的。 后来，人们发现了1.0.0版的错误。 需要代码更正。 由于它已经包含2.0.0代码，因此无法在中继上执行。 必须使用标签1.0.0。 因此，需要从标签1.0.0创建分支。

但是为1.0.0错误创建的代码更正呢？ 它不应该包含在2.0.0版中吗？ 是的，应该这样做，但是由于不能将分支1.0.x合并回主干（它来自标签1.0.0），因此需要另一种解决方案。 通常，将创建一个包含来自分支1.0.x的代码更正的补丁 ，并通过从主干中签出在本地应用它。 然后，此代码更正可以提交回主干，它将成为版本2.0.0的一部分。

从标记发布创建的分支具有自己的生命。 它们被称为维护分支，并且在维护长发行版本时仍然有效。 与主干分支相反，它们永远不会与原始标签合并回去。 您可以将它们视为标记发布的小箱子。

参考：在技术说明博客上，从我们的JCG合作伙伴 Jerome Versrynge 解释树干，分支，标签和相关概念 。

翻译自: https://www.javacodegeeks.com/2012/11/trunk-branch-tag-and-related-concepts.html