我已经在Subversion(我猜通用存储库)讨论中看到了很多这样的话.在过去的几年里,我一直在为我的项目使用SVN,但我从未掌握过这些目录的完整概念.
他们的意思是什么？
嗯,不确定我同意Nick重新标记类似于分支.标签只是一个标记
Trunk将成为开发的主体,源于项目的开始直到现在.
分支将是从主干中的某个点派生的代码的副本,该代码用于对代码进行重大更改,同时保持主干中代码的完整性.如果主要变更按计划运作,它们通常会合并回主干.
标记将是您希望保留的主干或分支上的时间点.保存的两个主要原因是这是软件的主要版本,无论是alpha版,beta版,RC版还是RTM版,或者在应用主干版本修改之前,这是软件中最稳定的一点.
在开源项目中,项目利益相关者不接受主干的主要分支可以成为分支的基础- 例如,与其他源代码共享共同起源的完全独立的项目.
首先,正如@AndrewFinnell和@KenLiu指出的那样,在SVN中,目录名称本身并不代表什么 - "主干,分支和标签"只是大多数存储库使用的常见约定.并非所有项目都使用所有目录(根本不使用"标签"),事实上,没有什么能阻止你将它们称为任何你想要的东西,尽管破坏惯例常常令人困惑.
我将描述分支和标记的最常见使用场景,并给出一个如何使用它们的示例场景.
主干:主要开发区域.这是您下一个主要版本的代码所在的位置,并且通常具有所有最新功能.
分支:每次发布主要版本时,都会创建一个分支.这允许您进行错误修复并制作新版本,而无需发布最新的 - 可能未完成或未经测试的功能.
标签:每次发布版本(最终版本,发布候选版本(RC)和测试版)时,都会为其制作标记.这为您提供了该状态下代码的时间点副本,允许您在过去的版本中返回并重现任何错误,或者完全按照原样重新发布过去的版本.SVN中的分支和标签是轻量级的 - 在服务器上,它不会生成文件的完整副本,只是标记"这些文件在此版本中被复制",只占用几个字节.考虑到这一点,您永远不应该担心为任何已发布的代码创建标记.正如我之前所说,标签经常被省略,而更改日志或其他文档在发布时会澄清修订号.
例如,假设你开始一个新项目.你开始在"trunk"中工作,最终将作为1.0版本发布.
trunk/ - 开发版,很快就会是1.0
分支/ - 空
1.0.0完成后,将trunk分支到一个新的"1.0"分支,并创建一个"1.0.0"标记.现在继续研究最终将继续在后备箱中继续使用1.1.
trunk/ - 开发版,很快将是1.1
branches/1.0 - 1.0.0发布版本
tags/1.0.0 - 1.0.0发布版本
您在代码中遇到一些错误,并在trunk中修复它们,然后将修复程序合并到1.0分支.您也可以执行相反的操作,并修复1.0分支中的错误,然后将它们合并回主干,但通常项目坚持单向合并以减少丢失某些内容的机会.有时一个bug只能在1.0中修复,因为它在1.1中已经过时了.这并不重要:您只想确保不使用1.0中修复的相同错误发布1.1.
trunk/ - 开发版,很快将是1.1
branches/1.0 - 即将发布的1.0.1版本
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 - 即将发布的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)的工作继续在trunk中继续工作,但是在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".(除此之外,语义版本控制是如何进行版本号的一个很好的指南).
除了Nick所说的,您还可以在Streamed Lines中找到更多信息:并行软件开发的分支模式
在这个图中main是主干,rel1-maint是一个分支,1.0是一个标签.
通常(工具不可知视图),分支是用于并行开发的机制.SCM可以具有0到n个分支.Subversion有0.
Trunk是Subversion 推荐的主要分支,但您绝不会被迫创建它.你可以称之为'主'或'发布',或者根本就没有!
Branch代表了一项开发工作.它永远不应该在资源(如'vonc_branch')之后命名,而是在:
目的'myProject_dev'或'myProject_Merge'
释放周长'myProjetc1.0_dev'or myProject2.3_Merge'或'myProject6..2_Patch1'......
标签是文件的快照,以便轻松返回到该状态. 问题是Subversion中的标签和分支是相同的.我肯定会推荐偏执的方法:
您可以使用Subversion提供的访问控制脚本之一来阻止任何人做任何事情,除了在标签区域中创建新副本.
标签是最终的.它的内容永远不会改变.决不.永远.你在发行说明中忘了一行？创建一个新标签.废弃或删除旧的.
现在,我读了很多关于"在这样的分支中合并这样的东西,然后最终在主干分支中".这称为合并工作流程,这里没有强制要求.这不是因为你有一个主干分支,你必须合并回任何东西.
按照惯例,trunk分支可以表示开发的当前状态,但这是一个简单的顺序项目,即具有以下项目的项目:
没有'提前'开发(用于准备下一个版本意味着这些更改,它们与当前的'主干'开发不兼容)
没有大规模的重构(用于测试新的技术选择)
没有长期维护以前的版本
因为有了这些场景中的一个(或全部),你会得到四个"中继",四个"当前的发展",并不是你在那些并行开发中所做的一切都必须在"主干"中合并.
在SVN中,标签和分支非常相似.
Tag =定义的时间片,通常用于发布
Branch =也是一个定义的时间片,开发可以继续,通常用于主要版本,如1.0,1.5,2.0等,然后当你发布时标记分支.这使您可以继续支持生产版本,同时继续进行中断更改
Trunk =开发工作空间,这是所有开发应该发生的地方,然后更改从分支版本合并回来.
它们实际上没有任何正式含义.文件夹是SVN的文件夹.它们是组织项目的普遍接受的方式.
行李箱是您保持主要发展方向的地方.您可以在分支文件夹中创建分支,这些分支很难在短文中解释.
分支是项目子集的副本,您可以与主干分开处理.也许是因为实验可能不会出现在任何地方,或者可能是下一个版本,当它变得稳定时你将稍后合并回主干.
tags文件夹用于创建存储库的标记副本,通常是在发布检查点.
但就像我说的,对SVN来说,文件夹是一个文件夹.branch,trunk和标签只是一个惯例.
我正在大量使用"复制"这个词.SVN实际上并不在存储库中制作完整的东西副本.
该干线是发展线保持最新的源代码和功能.它应该有最新的错误修复程序以及添加到项目中的最新功能.
该分支通常用来做一些事情从主干(或其他发展路线),否则将客场打破构建.新功能通常构建在分支中,然后合并回主干.分支通常包含不一定被批准用于其分支的开发线的代码.例如,程序员可以尝试对分支中的某些内容进行优化,并且只有在优化满意后才会在开发行中合并.
该标签是在特定时间存储库的快照.这些都不应该发展.它们通常用于获取发布到客户端的副本,以便您可以轻松访问客户端正在使用的内容.
这是一个非常好的存储库指南的链接:
源控制HOWTO
维基百科中的文章也值得一读.
现在这就是软件开发的问题,对于任何事情都没有一致的知识,每个人似乎都有自己的方式,但这是因为无论如何它都是一个相对年轻的学科.
这是我简单明了的方法,
trunk - trunk目录包含最新,已批准和合并的工作主体.与许多人承认的相反,我的行李箱仅用于清洁,整洁,批准的工作,而不是开发区域,而是一个释放区域.
在某个给定的时间点,当主干似乎已准备好释放时,它会被标记并释放.
分支 - 分支目录包含实验和正在进行的工作.分支机构的工作停留在那里,直到被批准合并到主干.对我来说,这是完成所有工作的领域.
例如:我可以在产品的第五轮开发中使用iteration-5分支,也可以在第九轮实验中使用原型9分支,依此类推.
tags - tags目录包含已批准的分支和主干版本的快照.每当分支机构被批准合并到主干中,或者发布主干时,都会在标签下创建已批准的分支或主干版本的快照.
我想有标签,我可以很容易地来回穿过时间点兴趣点.
我发现关于SVN时,我一直在寻找了网站这个伟大的教程作者的的OpenCV的 2计算机视觉应用程序设计食谱,我想我应该分享.
他有一个关于如何使用SVN的教程以及短语"trunk","tag"和"branch"的含义.
直接从他的教程中引用:
您的团队当前正在使用的当前版本的软件项目通常位于名为trunk的目录下.随着项目的发展,开发人员更新版本修复错误,添加新功能)并在该目录下提交更改.
在任何给定的时间点,您可能希望冻结版本并捕获软件的快照,就像在开发的这个阶段一样.这通常对应于您的软件的官方版本,例如,您将提供给客户的版本.这些快照位于项目的tags目录下.
最后,在某些时候为您的软件创建新的开发线通常很有用.例如,当您希望测试替代实现时,您必须修改软件,但在决定是否采用新解决方案之前,您不希望将这些更改提交到主项目.然后,主要团队可以继续处理项目,而其他开发人员则可以使用原型.您可以将项目的这些新开发线放在名为branches的目录下.
trunk目录是您可能最熟悉的目录,因为它用于保存最新的更改.您的主代码库应该在trunk中.
分支目录用于保存您的分支,无论它们是什么.
tags目录基本上用于标记某组文件.你可以在发布版本中执行此操作,在这些修订版中你希望"1.0"是这些文件,在这些版本中你想要"1.1"这些文件.您通常不会在制作标签后对其进行修改.有关标记的更多信息,请参阅第4章分支和合并(在版本控制中使用Subversion).
每个人定义略有不同的原因之一是因为Subversion 对分支和标签实现零支持.Subversion基本上说:我们在其他系统中查看了功能齐全的分支和标签,并没有发现它们有用,所以我们没有实现任何功能.只是做一个拷贝与一个名称的新目录约定代替.当然,每个人都可以自由地拥有略微不同的约定.要了解真实标记与纯粹复制+命名约定之间的区别,请参阅Wikipedia条目Subversion标记和分支.
Tag =定义的时间片,通常用于发布
我认为这通常意味着"标签".但是在Subversion中:
它们实际上没有任何正式含义.文件夹是SVN的文件夹.
我发现相当混乱:一个对分支或标签一无所知的修订控制系统.从实现的角度来看,我认为Subversion创建"副本"的方式非常聪明,但我不得不知道它是我所谓的漏洞抽象.
或许我刚刚使用CVS的时间太长了.
我认为一些混淆来自于标签的概念和SVN中的实现之间的区别.对于SVN,标签是一个分支,它是一个副本.修改标签被认为是错误的,事实上,如果您尝试使用路径中的../tags/ ..修改任何内容,TortoiseSVN等工具会发出警告.
我不确定'标签'是什么,但分支是一个相当常见的源控制概念.
基本上,分支是一种在不影响主干的情况下处理代码更改的方法.假设您要添加一个相当复杂的新功能.您希望能够在进行更改时签入更改,但在完成该功能之前,不要让它影响主干.
首先,你要创建一个分支.这基本上是您创建分支时的主干副本.然后,您将在分支机构中完成所有工作.在分支中进行的任何更改都不会影响主干,因此主干仍然可用,允许其他人继续在那里工作(如进行错误修正或小增强).完成功能后,您将分支重新集成到主干中.这会将所有更改从分支移动到主干.
人们用于分支的模式有很多种.如果您的产品一次支持多个主要版本,通常每个版本都是一个分支.在我工作的地方,我们有一个QA分支和一个生产分支.在将代码发布到QA之前,我们将更改集成到QA分支,然后从那里进行部署.在发布到生产时,我们从QA分支集成到生产分支,因此我们知道生产中运行的代码与QA测试的代码相同.
这是关于分支的维基百科条目,因为它们可能比我能更好地解释事情.:)
京公网安备 11010802040832号 | 京ICP备19059560号-6 