Subversion 存储库中的“分支”、“标签”和“主干”是什么意思？

StackOverflow https://stackoverflow.com/questions/16142

题

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

他们的意思是什么？

有帮助吗？

解决方案

嗯，不确定我是否同意尼克重新标记类似于分支。标签只是一个标记

  • 树干 将是开发的主体，从项目开始到现在。

  • 分支 将是从主干中某个点派生的代码副本，用于对代码进行重大更改，同时保留主干中代码的完整性。如果主要变更按计划进行，它们通常会合并回主干。

  • 标签 将是您希望保留的树干或树枝上的一个时间点。保留的两个主要原因是，要么这是软件的主要版本，无论是 alpha、beta、RC 还是 RTM，要么这是在主干上应用重大修订之前软件的最稳定点。

在开源项目中，未被项目干系人接受到主干的主要分支可以成为 叉子 ——例如，与其他源代码共享共同起源的完全独立的项目。

分支子树和标签子树与主干的区别如下：

Subversion 允许系统管理员创建 钩子脚本 当某些事件发生时触发执行；例如，向存储库提交更改。对于典型的 Subversion 存储库实现来说，将任何包含“/tag/”的路径在创建后进行写保护是很常见的；最终结果是，标签一旦创建，就是不可变的（至少对于“普通”用户而言）。这是通过钩子脚本完成的，该脚本通过防止进一步的更改来强制不变性，如果 标签 是更改对象的父节点。

自 1.5 版本以来，Subversion 还添加了与“分支合并跟踪”相关的功能，以便将更改提交给 分支 可以合并回主干，支持增量、“智能”合并。

其他提示

首先，正如 @AndrewFinnell 和 @KenLiu 指出的那样，在 SVN 中，目录名称本身没有任何意义——“主干、分支和标签”只是大多数存储库使用的常见约定。并非所有项目都使用所有目录（根本不使用“标签”是相当常见的），事实上，没有什么可以阻止您随意称呼它们，尽管打破约定通常会令人困惑。

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

  • 树干: ：主要开发区。这是代码的下一个主要版本所在的位置，并且通常具有所有最新功能。

  • 分支机构: ：每次发布主要版本时，都会创建一个分支。这使您可以修复错误并发布新版本，而无需发布最新的（可能是未完成或未经测试的）功能。

  • 标签: ：每次发布版本（最终版本、候选版本 (RC) 和测试版）时，您都会为其创建一个标签。这为您提供了代码在该状态下的时间点副本，允许您在必要时返回并重现过去版本中的任何错误，或者完全按原样重新发布过去的版本。SVN 中的分支和标签是轻量级的 - 在服务器上，它不会制作文件的完整副本，只是一个标记，表示“这些文件是在此版本中复制的”，仅占用几个字节。考虑到这一点，您永远不应该担心为任何已发布的代码创建标签。正如我之前所说，标签经常被省略，而是在发布时通过更改日志或其他文档来阐明修订号。

例如，假设您开始一个新项目。您开始在“主干”中工作，最终将发布 1.0 版。

  • trunk/ - 开发版本，即将成为 1.0
  • 分支/ - 空

1.0.0 完成后，您将主干分支到新的“1.0”分支，并创建一个“1.0.0”标签。现在，最终的 1.1 版本的工作仍在 trunk 中继续进行。

  • trunk/ - 开发版本， 即将成为 1.1
  • 分支/1.0 - 1.0.0 发布版本
  • Tags/1.0.0 - 1.0.0 发布版本

您在代码中遇到一些错误，并在主干中修复它们，然后将修复合并到 1.0 分支。您也可以做相反的事情，修复 1.0 分支中的错误，然后将它们合并回主干，但通常项目坚持单向合并只是为了减少丢失某些内容的机会。有时，一个错误只能在 1.0 中修复，因为它在 1.1 中已过时。这并不重要：您只想确保发布的 1.1 版本中不会包含 1.0 中已修复的相同错误。

  • trunk/ - 开发版本，即将成为 1.1
  • 分支/1.0 - 即将发布 1.0.1 版本
  • Tags/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 版本
  • Tags/1.0.0 - 1.0.0 发布版本
  • Tags/1.0.1 - 1.0.1 发布版本

最终您几乎准备好发布 1.1，但您想先进行测试版。在这种情况下，您可能会创建一个“1.1”分支和一个“1.1beta1”标签。现在，1.2（或可能是 2.0）的工作将在主干中继续进行，但 1.1 的工作将在“1.1”分支中继续进行。

  • trunk/ - 开发版本， 很快就会是1.2
  • Branches/1.0 - 即将发布的 1.0.2 版本
  • Branches/1.1 - 即将发布的 1.1.0 版本
  • Tags/1.0.0 - 1.0.0 发布版本
  • Tags/1.0.1 - 1.0.1 发布版本
  • Tags/1.1beta1 - 1.1 beta 1 发布版本

一旦你发布了 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 - 实验性功能分支

这个想法是当你正在做一些破坏性的事情（这会阻碍或干扰其他人做他们的工作），一些实验性的事情（甚至可能不会成功），或者可能只是一些需要很长时间的事情（当您准备从主干分支 1.2 时，您担心它是否会阻止 1.2 版本），您可以在分支中单独执行此操作。通常，您可以通过始终将更改合并到主干中来使其与主干保持同步，这使得完成后更容易重新集成（合并回主干）。

另请注意，我在这里使用的版本控制方案只是众多版本控制方案之一。有些团队会将错误修复/维护版本作为 1.1、1.2 等，并将重大更改作为 1.x、2.x 等。这里的用法是相同的，但是您可以将分支命名为“1”或“1.x”，而不是“1.0”或“1.0.x”。（在旁边， 语义版本控制 是关于如何处理版本号的很好的指南）。

除了尼克所说的之外，您还可以在以下位置找到更多信息： 流线：并行软件开发的分支模式

enter image description here

在这张图中 main 是树干， rel1-maint 是一个分支并且 1.0 是一个标签。

一般来说 （与工具无关的观点），分支是用于并行开发的机制。一个 SCM 可以有 0 到 n 个分支。颠覆有 0。

  • 树干 是一个主要分支 受到推崇的 通过颠覆, ，但您绝不会被迫创建它。您可以将其称为“主要”或“发布”，或者根本没有！

  • 分支 代表一种开发努力。它永远不应该以资源（如“vonc_branch”）命名，而应以：

    • 目的“myProject_dev”或“myProject_Merge”
    • 发布边界“myProjetc1.0_dev”或“myProject2.3_Merge”或“myProject6..2_Patch1”...

  • 标签 是文件的快照，以便轻松返回到该状态。问题是 Subversion 中的标签和分支是相同的. 。我肯定会推荐偏执的方法：

    您可以使用 Subversion 提供的访问控制脚本之一来阻止任何人执行除在标记区域中创建新副本之外的任何操作。

标签是最终的。它的内容永远不应该改变。绝不。曾经。您忘记了发行说明中的​​一行吗？创建一个新标签。废弃或删除旧的。

现在，我读了很多关于“在这样那样的分支中合并回来这样那样的内容，然后最终合并到主干分支中”。它被称作 合并工作流程 并且有 这里没有强制要求. 。并不是因为你有一个主干分支 必须合并回来 任何事物。

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

  • 没有“提前”开发（准备下一个版本意味着这些更改与当前的“主干”开发不兼容）
  • 无需大规模重构（用于测试新技术选择）
  • 无需对先前版本进行长期维护

因为对于这些场景中的一个（或全部），您会得到四个“主干”，四个“当前开发”，并且您在这些并行开发中所做的所有操作不一定都必须合并回“主干”中。

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

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

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

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

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

  • 主干是你保持主线发展的地方。分支文件夹是您可以创建分支的地方，这很难在简短的文章中解释清楚。

  • 分支是项目子集的副本，您可以将其与主干分开处理。也许是为了实验，可能不会去任何地方，或者也许是为了下一个版本，当它变得稳定时，您稍后会将其合并回主干。

  • 标签文件夹用于创建存储库的标记副本，通常在发布检查点。

但就像我说的，对于 SVN，文件夹就是文件夹。 branch, trunk 和标签只是一种约定。

我随意使用“复制”这个词。SVN 实际上并不制作存储库中内容的完整副本。

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

这 分支机构 通常用于远离主干（或其他开发线）做一些事情，否则会 休息 构建。新功能通常构建在分支中，然后合并回主干中。分支通常包含不一定被其分支的开发线批准的代码。例如，程序员可以尝试对分支中的某些内容进行优化，只有在优化令人满意后才合并回开发线。

这 标签 是存储库在特定时间的快照。这些不应发生任何发展。它们最常用于获取发布给客户端的内容的副本，以便您可以轻松访问客户端正在使用的内容。

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

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

这就是软件开发的问题，任何事情都没有一致的知识，每个人似乎都有自己的方式，但那是因为它无论如何都是一个相对年轻的学科。

这是我的简单简单的方法

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

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

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

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

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

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

当我查找 SVN 的网站时，我发现了这个关于 SVN 的很棒的教程 作者 的 开放式计算机视觉 2 计算机视觉应用程序编程食谱，我认为我应该分享。

他有一个关于如何使用 SVN 以及短语“trunk”、“tag”和“branch”含义的教程。

直接引用他的教程：

您的团队当前正在处理的软件项目的当前版本通常位于名为的目录下 树干. 。随着项目的发展，开发人员更新该版本（修复错误、添加新功能）并在该目录下提交更改。

在任何给定的时间点，您可能希望冻结版本并捕获软件在开发的此阶段的快照。这通常对应于您的软件的官方版本，例如您将交付给客户的版本。这些快照位于 标签 您的项目的目录。

最后，在某些时候为您的软件创建新的开发线通常很有用。例如，当您希望测试必须修改软件的替代实现，但在决定是否采用新解决方案之前，您不想将这些更改提交到主项目时，就会发生这种情况。然后，主团队可以继续处理该项目，而其他开发人员则处理原型。您可以将项目的这些新开发线放在名为的目录下 分支机构.

trunk 目录是您可能最熟悉的目录，因为它用于保存最近的更改。您的主要代码库应该位于主干中。

分支目录用于保存您的分支，无论它们是什么。

标签目录基本上用于标记一组特定的文件。您可以对发布之类的内容执行此操作，您希望“1.0”是这些修订版中的这些文件，而“1.1”是这些修订版中的这些文件。标签一旦制作完成，您通常不会对其进行修改。有关标签的更多信息，请参见 第 4 章。分支与合并 （在 使用 Subversion 进行版本控制).

每个人的定义略有不同的原因之一是因为 Subversion 实现了 零 支持分支和标签。颠覆基本上说： 我们看了 功能齐全 其他系统中的分支和标签并没有发现它们有用，所以我们没有实现任何东西。只需将其复制到具有名称的新目录中即可 习俗 反而. 。当然，每个人都可以自由地制定略有不同的惯例。要了解a之间的区别 真实的 标签和仅复制 +命名大会请参见Wikipedia条目 Subversion 标签和分支.

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

我认为这就是“标签”的典型含义。但在颠覆中：

它们实际上没有任何正式意义。文件夹是 SVN 的文件夹。

我发现这很令人困惑：一个对分支或标签一无所知的版本控制系统。从实现的角度来看，我认为 Subversion 创建“副本”的方式非常聪明，但我必须了解它，我称之为 漏洞抽象.

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

我认为一些混乱来自于标签的概念和 SVN 中的实现之间的差异。对于 SVN 来说，标签是一个分支，也是一个副本。修改标签被认为是错误的，事实上，如果您尝试使用 ../tags/.. 修改任何内容，TortoiseSVN 等工具会向您发出警告。在路径中。

我不太确定“标签”是什么，但分支是一个相当常见的源代码控制概念。

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

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

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

这是 分支上的维基百科条目, ，因为他们可能比我更好地解释事情。:)

对于熟悉GIT的人来说，GIT中的master就相当于SVN中的trunk。

分支和标签在 GIT 和 SVN 中具有相同的术语。

树干 ：敏捷的每个冲刺完成后，我们都会推出部分可交付的产品。这些版本保存在主干中。

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

标签 ：每次我们发布部分可交付的产品类型的测试版时，我们都会为其制作一个标签。这为我们提供了当时可用的代码，允许我们在开发过程中的某个时刻需要时返回到该状态。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top