我在 Subversion(我猜是通用存储库)讨论中经常看到这些词。
在过去的几年里,我一直在我的项目中使用SVN,但我从未掌握这些目录的完整概念。
他们的意思是什么?
我在 Subversion(我猜是通用存储库)讨论中经常看到这些词。
在过去的几年里,我一直在我的项目中使用SVN,但我从未掌握这些目录的完整概念。
他们的意思是什么?
嗯,不确定我是否同意 Nick re 标记类似于分支。标签只是一个标记
主干将是开发的主体,从项目开始到现在。
分支将是从主干中某个点派生的代码副本,用于对代码进行重大更改,同时保持主干中代码的完整性。如果主要更改按计划进行,它们通常会合并回主干。
标记将是您希望保留的主干或分支上的时间点。保留的两个主要原因是要么这是软件的主要版本,无论是 alpha、beta、RC 还是 RTM,或者这是在应用主干上的主要修订之前软件的最稳定点。
在开源项目中,项目利益相关者不接受主干的主要分支可以成为分叉的基础——例如,与其他源代码共享同一来源的完全独立的项目。
分支和标记子树通过以下方式与主干区分开来:
Subversion 允许系统管理员创建钩子脚本,这些脚本在某些事件发生时触发执行;例如,提交对存储库的更改。典型的 Subversion 存储库实现在创建后将包含“/tag/”的任何路径视为写保护是很常见的;最终结果是标签一旦创建,就是不可变的(至少对于“普通”用户而言)。这是通过钩子脚本完成的,如果tag是更改对象的父节点,则通过防止进一步更改来强制执行不变性。
从 1.5 版开始,Subversion 还添加了与“分支合并跟踪”相关的功能,以便提交到分支的更改可以合并回主干,支持增量、“智能”合并。
首先,正如@AndrewFinnell 和@KenLiu 指出的那样,在SVN 中,目录名称本身没有任何意义——“主干、分支和标签”只是大多数存储库使用的通用约定。并非所有项目都使用所有目录(完全不使用“标签”是相当普遍的),事实上,没有什么能阻止你随意调用它们,尽管打破惯例常常令人困惑。
我将描述可能最常见的分支和标签使用场景,并举例说明如何使用它们。
树干:主要开发区。这是您代码的下一个主要版本所在的位置,并且通常具有所有最新功能。
分支:每次发布主要版本时,都会创建一个分支。这允许您进行错误修复并发布新版本,而无需发布最新的(可能是未完成或未经测试的)功能。
标签:每次发布版本(最终版本、候选版本 (RC) 和测试版)时,您都会为其制作标签。这为您提供了该状态下代码的时间点副本,允许您在必要时返回并重现过去版本中的任何错误,或者完全按原样重新发布过去的版本。SVN 中的分支和标签是轻量级的 - 在服务器上,它不会制作文件的完整副本,只是一个标记说“这些文件是在此修订版中复制的”,只占用几个字节。考虑到这一点,您永远不必担心为任何已发布的代码创建标签。正如我之前所说,标签通常被省略,而是在发布时通过变更日志或其他文档阐明修订号。
例如,假设您开始一个新项目。您开始在“主干”中工作,最终将作为 1.0 版发布。
1.0.0 完成后,将主干分支到一个新的“1.0”分支,并创建一个“1.0.0”标签。现在,在主干中继续开发最终将成为 1.1 的内容。
您在代码中遇到了一些错误,并在主干中修复它们,然后将修复合并到 1.0 分支。你也可以做相反的事情,修复 1.0 分支中的错误,然后将它们合并回主干,但通常项目坚持单向合并只是为了减少丢失某些东西的机会。有时一个错误只能在 1.0 中修复,因为它在 1.1 中已过时。这并不重要:您只需要确保您发布的 1.1 版本中不会出现 1.0 版本中已修复的相同错误。
一旦找到足够多的错误(或者可能是一个严重错误),您就决定发布 1.0.1 版本。因此,您从 1.0 分支创建一个标记“1.0.1”,然后发布代码。此时,主干将包含 1.1,而“1.0”分支包含 1.0.1 代码。下次您发布 1.0 的更新时,将是 1.0.2。
最终你几乎准备好发布 1.1,但你想先做一个测试版。在这种情况下,您可能会执行“1.1”分支和“1.1beta1”标签。现在,在主干中继续开发 1.2(或可能是 2.0),但在“1.1”分支中继续开发 1.1。
一旦你发布了 1.1 final,你从“1.1”分支做一个“1.1”标签。
如果愿意,您还可以继续维护 1.0,在所有三个分支(1.0、1.1 和主干)之间移植错误修复。重要的一点是,对于您维护的每个主要软件版本,您都有一个包含该版本代码的最新版本的分支。
分支的另一个用途是用于特征。这是您分支主干(或您的发布分支之一)并单独开发新功能的地方。功能完成后,将其重新合并并删除分支。
这个想法是当你在做一些破坏性的事情(这会阻碍或干扰其他人做他们的工作),一些实验性的事情(甚至可能无法进入),或者可能只是一些需要很长时间的事情(当您准备从主干分支 1.2 时,您担心如果它阻止 1.2 版本),您可以在分支中单独执行此操作。通常,您通过始终将更改合并到主干来使其与主干保持同步,这使得完成后重新集成(合并回主干)变得更容易。
另请注意,我在这里使用的版本控制方案只是其中之一。一些团队会将错误修复/维护版本作为 1.1、1.2 等进行,而将主要更改作为 1.x、2.x 等。这里的用法是相同的,但您可以将分支命名为“1”或“1” .x”而不是“1.0”或“1.0.x”。(此外,语义版本控制是一个很好的指导如何做版本号)。
除了 Nick 所说的之外,您还可以在Streamed Lines:并行软件开发的分支模式中找到更多信息
在这个图main
中是主干,rel1-maint
是一个分支,1.0
是一个标签。
通常(与工具无关的观点),分支是用于并行开发的机制。一个 SCM 可以有 0 到 n 个分支。颠覆有 0。
Trunk是Subversion推荐的主分支,但你绝不会被迫创建它。您可以将其称为“主要”或“发布”,或者根本没有!
分支代表开发工作。它永远不应该以资源命名(如'vonc_branch'),但应在:
标记是文件的快照,以便轻松返回该状态。 问题是标签和分支在 Subversion 中是相同的。我肯定会推荐偏执的方法:
您可以使用 Subversion 提供的访问控制脚本之一来防止任何人做任何事情,除了在标签区域创建新副本。
一个标签是最终的。它的内容永远不应该改变。绝不。曾经。您忘记了发行说明中的一行?创建一个新标签。过时或删除旧的。
现在,我读了很多关于“在某某分支中合并某某,然后最终在主干分支中”的内容。这称为合并工作流,这里没有任何强制性。这不是因为你有一个主干分支,你必须合并任何东西。
按照惯例,主干分支可以代表您开发的当前状态,但这是一个简单的顺序项目,即具有以下内容的项目:
因为在这些场景中的一个(或所有)情况下,您会得到四个“主干”,四个“当前开发”,而并非您在这些并行开发中所做的所有事情都必须合并回“主干”中。
在 SVN 中,标签和分支非常相似。
Tag = 定义的时间片,通常用于发布
分支= 也是一个定义的时间片,开发可以继续进行,通常用于主要版本,如 1.0、1.5、2.0 等,然后在发布时标记分支。这使您可以继续支持生产版本,同时继续在主干中进行重大更改
主干= 开发工作空间,这是所有开发应该发生的地方,然后更改从分支版本合并回来。
它们实际上没有任何正式意义。文件夹是 SVN 的文件夹。它们是一种普遍接受的组织项目的方式。
主干是您保留开发主线的地方。分支文件夹是您可以创建分支的地方,这在简短的帖子中很难解释。
分支是您的项目子集的副本,您与主干分开工作。也许它是用于可能不会去任何地方的实验,或者它可能是用于下一个版本,当它变得稳定时,您将稍后将其合并回主干。
tags 文件夹用于创建存储库的标记副本,通常在发布检查点。
但就像我说的,对于 SVN,文件夹就是文件夹。branch
,trunk
和 tag 只是一个约定。
我在自由地使用“复制”这个词。SVN 实际上并没有在存储库中制作完整的副本。
主干是拥有最新源代码和功能的开发线。它应该包含最新的错误修复以及添加到项目中的最新功能。
分支通常用于在主干(或其他开发线)之外做一些事情,否则会破坏构建。新功能通常构建在分支中,然后合并回主干。分支通常包含不一定被批准用于其分支的开发线的代码。例如,程序员可以尝试对分支中的某些内容进行优化,并且只有在优化令人满意时才合并回开发线。
标签是存储库在特定时间的快照。在这些方面不应该发生任何发展。它们最常用于获取发布给客户的内容的副本,以便您可以轻松访问客户正在使用的内容。
这是一个非常好的存储库指南的链接:
维基百科的文章也值得一读。
现在这就是软件开发的问题,任何事情都没有一致的知识,每个人似乎都有自己的方式,但那是因为它无论如何都是一个相对年轻的学科。
这是我简单的方法,
主干- 主干目录包含最新、批准和合并的工作主体。与许多人所承认的相反,我的后备箱仅用于干净、整洁、经过批准的工作,而不是开发区,而是发布区。
在某个给定时间点,当主干似乎已准备好释放时,它会被标记并释放。
分支- 分支目录包含实验和正在进行的工作。分支下的工作会一直留在那里,直到被批准并入主干。对我来说,这是完成所有工作的地方。
例如:我可以有一个迭代 5分支用于产品的第五轮开发,也许有一个原型 9分支用于第九轮试验,等等。
tags - 标签目录包含已批准的分支和主干版本的快照。每当一个分支被批准合并到主干中,或者主干发布了一个版本,批准的分支或主干发布的快照就会在标签下创建。
我想有了标签,我可以很容易地在时间上来回跳转到兴趣点。
当我在查找OpenCV 2 Computer Vision Application Programming Cookbook 的作者的网站时,我发现了这个关于 SVN 的很棒的教程,我想我应该分享一下。
他有一个关于如何使用 SVN 以及短语“trunk”、“tag”和“branch”含义的教程。
直接引用他的教程:
您的团队当前正在使用的软件项目的当前版本通常位于名为trunk的目录下。随着项目的发展,开发人员更新该版本修复错误,添加新功能)并在该目录下提交他的更改。
在任何给定的时间点,您可能想要冻结版本并捕获软件在开发的这个阶段的快照。这通常对应于您的软件的官方版本,例如,您将交付给客户的版本。这些快照位于项目的tags目录下。
最后,在某些时候为您的软件创建新的开发线通常很有用。例如,当您希望测试一个替代实现时,您必须修改您的软件,但您不想将这些更改提交到主项目,直到您决定是否采用新解决方案时,就会发生这种情况。然后,主要团队可以继续从事项目工作,而其他开发人员则从事原型工作。您可以将项目的这些新开发线放在一个名为branches的目录下。
主干目录是您可能最熟悉的目录,因为它用于保存最近的更改。您的主要代码库应该在主干中。
分支目录用于保存您的分支,无论它们是什么。
tags 目录基本上是用于标记一组文件。您为发布之类的事情执行此操作,您希望“1.0”成为这些修订版中的这些文件,而“1.1”成为这些修订版中的这些文件。制作标签后,您通常不会对其进行修改。有关标签的更多信息,请参阅第 4 章。分支和合并(在带有 Subversion 的版本控制中)。
每个人定义略有不同的原因之一是因为 Subversion 实现了对分支和标签的零支持。Subversion 基本上说:我们在其他系统中查看了全功能的分支和标签,但没有发现它们有用,所以我们没有实现任何东西。只需将副本复制到具有名称约定的新目录即可。那么当然每个人都可以自由地有稍微不同的约定。要了解真实标签和单纯的复制 + 命名约定之间的区别,请参阅 Wikipedia 条目Subversion 标签和分支。
我认为一些混淆来自标签的概念和 SVN 中的实现之间的差异。对于 SVN,标签是一个分支,它是一个副本。修改标签被认为是错误的,事实上,如果您尝试修改路径中带有 ../tags/.. 的任何内容,TortoiseSVN 等工具会警告您。
我不太确定“标签”是什么,但分支是一个相当常见的源代码控制概念。
基本上,分支是一种在不影响主干的情况下对代码进行更改的方法。假设您想添加一个相当复杂的新功能。您希望能够在进行更改时签入更改,但在完成该功能之前不希望它影响主干。
首先你要创建一个分支。这基本上是您创建分支时的主干副本。然后,您将在分支中完成所有工作。在分支中所做的任何更改都不会影响主干,因此主干仍然可用,允许其他人继续在那里工作(例如进行错误修复或小改进)。完成功能后,您会将分支重新集成到主干中。这会将您的所有更改从分支移动到主干。
人们用于分支的模式有很多。如果您的产品同时支持多个主要版本,通常每个版本都是一个分支。在我工作的地方,我们有一个 QA 分支和一个生产分支。在将代码发布给 QA 之前,我们将更改集成到 QA 分支,然后从那里进行部署。当发布到生产时,我们从 QA 分支集成到生产分支,因此我们知道在生产中运行的代码与 QA 测试的代码相同。
这是有关分支的维基百科条目,因为它们可能比我能更好地解释事情。:)
主干:在敏捷中的每个冲刺完成后,我们推出了一个部分可交付的产品。这些版本保存在主干中。
分支:每个正在进行的 sprint 的所有并行开发代码都保存在分支中。
标签:每次我们发布部分可交付的产品类型的测试版时,我们都会为它制作一个标签。这为我们提供了当时可用的代码,如果在开发过程中的某个时间点需要,我们可以回到那个状态。
对于熟悉GIT的人来说,GIT中的master就相当于SVN中的trunk。
分支和标签在 GIT 和 SVN 中具有相同的术语。