《用SVN分支管理多版本》由会员分享，可在线阅读，更多相关《用SVN分支管理多版本（8页珍藏版）》请在金锄头文库上搜索。
1、用SVN分支管理多版本201-02-梁军1.目的为了在多个版本中并行开发，提高开发效率，保证各个版本和各个环境（开发、测试、主干）的独立，避免相互影响，减少最终发布时合并主干出现冲突的概率，降低冲突处理的难度，特编写该文档；2.原则多个版本（开发版本，测试版本，发布版本）；多次合并。3.Svn目录结构采用类似下面的目录结构：project|+-trunk|+-main.js(3.0版本的最新文件）-coon.js+-branches+|+-r1.0+ |+-main.js（1.x版本的最新文件）+ -coon.js+-r2.0|+-main.js（2.x版本的最新文件）-coon.js+-ta
2、gs(此目录只读)|+-r1.0|+-main.js（1.0版本的发布文件）-coon.js+-r1.+|+-main.js（1.版本的发布文件）+-coon.js+-r1.2|+-main.js（1.2版本的发布文件）-coon.js+-r1.3+|+-main.js（1.3版本的发布文件）+-coon.js+-r2.0|+-main.js（2.0版本的发布文件）-coon.js+-r2.1|+-main.js（2.1版本的发布文件）-coon.jstrunk：主干，是日常开发进行的地方。branches：分支。一些阶段性的relase版本，这些版本是可以继续进行开发和维护的，则放在bran
3、ches目录中，里面的版本全部基于trunk基础上建立的。tags：表示标签存放的目录，一般为只读写，存储阶段行发布版本，一般是基于分支上建立。4.流程Version 1.0开发是否已发布否给version 1.0打标签：tag_relase 1.0version 2.0开发是1.0版本是否需要修改否是基于tag_relase 1.0版本创建分支:dev1.0_fixedBugs在dev1.0_fixedBugs 上开发version 2.0开发是否可发布是否给dev1.0_fixedBugs 打标签：tagrelase 1.合并dev1.0_fixedBugs 到ersion 2.0是否进入
4、测试否是基于version 2.0 版本创建分支:dev2.0_testing是version 3.0开发在dev2.0_testing上进行fixed bug是否有新增加的功能是否基于version 3.0 版本创建分支:dev.version 4.0开发是后面的流程回到“在dev1.0_fixedBugs 上开发”后面的流程回到“version 1.0 开发”4.1.选定一个非常稳定的版本作为一个基础版本，也就是主干版本。要求该版本必须是稳定版本。(假设这个版本是1.0)，则当前目录结构为：project|+-trunk|+-main.js(1.0版本的最新文件）-coon.js+-bra
5、nches-tgs4.2.1.0版本开发完成并已发布，则直接在tags里面打个标签，并且新需求在主干上开发，此时主干版本变成2.0。则目录结果变成：project|+-trunk|+-main.js(2.0版本的最新文件）-coon.js+-branches-tgs+-tag_relase1.0(从主干复制过来，该版本和外网一致)4.3.如果发现外网版本1.0,有bug，或者有个新的需求，要基于在外网版本上开发，因为主干版本已和外网不一样，因此不能够在主干上直接开发，此时，在tag_relase1.0基础上建立一个分支，进行fixedbug或小功能需求开发，则目录结果为：projct|+-tr
6、unk|+-main.js(2.0版本的最新文件）-coon.js+-branches+dv_1.0_fixedBug(从tag_relase1.0复制过来)+-tags+-tag_relase1.04.在dev_1.0_fixedBug版本上进行fixedbug，或者在这个基础上进行部分小功能开发，在主干truck进行2.0开发；4.5.dev_1.0_fixedBug版本开发完毕，并正式上线，然后基于dev_1.0_fixedBug的基础上在tags里面打上标签tag，此时目录结果为:project|+-trunk|+-main.js(2.0版本的最新文件）-coon.js+-branch
7、es+dv_1.0_fixedBug+-tags+-tag_relase1.0+-trls.（从dev_1.0_fixedBug复制过来）4.6.根据需要选择性地把dev_1.0_fixedBug这个分支合并到主干truck。合并原则：低版本合并到高版本；换言之，低版本里面修改的bug，一定要合并到高版本中。这里的合并可以根据具体来定，如果是fixed，则一定要合并到主干truck中，但如果是小需求修改，并且不计划在后续版本中实现，则可以不合并相应代码。至于合并时间间隔问题，最长不能够超过一个礼拜，否则会引起冲突严重，加大合并难度。4.7.当主干上的2.0开发已经结束，进入测试阶段，此时可以规
8、划下一个版本3.0，则在当前主干truck上建立一个分支，目录结果为：project|+-trunk|+-main.js(3.0版本的最新文件）-coon.js+-branches+dv_1.0_fixedBug+dev_2.0_testing(从原来主干上2.0的版本基础上复制)-tags+-tag_relase1.0-trls.4.8此时在主干上开发3.0，在dev_2.0_testing上fixedbugs。后面步骤类似4.-4.7的步骤；4.9如果在2.0fixedbugs和3.0版本同时进行阶段，想规划下一个版本4.0，则可以考虑在3.0基础上再做一个分支，为了减少在4.0版本上的合
9、并，要求4.0版本的需求是属于新增功能，不能够对原来的文件有过多的修改，否则会引起代码冲突严重。project|+-trunk|+-main.js-coon.js+-dialg.js(因为新增功能而增加的文件4.0)-branches+dv_1.0_fixedBugdev_2.0_testing+3.(从原来主干上3.0的版本基础上复制)+-tags+-tag_relase1.0+-trls.4.10.2.0测试，3.0开发、4.0开发多个版本同时进行。5.优点和不足优点主要有：1、多个版本相互独立，互不影响2、通过分支与主干的合并，这样主干永远是最新、最高版本，并且都在后面的测试中，保证了质
10、量。不足：当版本比较多时候，低版本上的bug修改，需要合并到高版本，版本越多，合并的次数就越多。6.分支合并：6.1.使用BCompare手工合并；6.2.使用svn合并功能合并7.建议7.1.如果项目的周期比较长，和主干进行合并的次数也应该加大，以降低处理冲突的难度。7.2.要求开发人员养成增加注释(log)习惯，方便后期对代码修改的跟踪。建议svn配置成强制添加注释，方可以提交代码。注释主要有下面类型：7.2.1.新增功能：用功能需求作为注释，可以概括为简单的一句话。7.2.fixedbug:用bug的标题、url作为注释；7.2.3.合并：必须要描述清楚合并来源。eg:mergfromdev_1.0_fixedBugbranch.7.3.每次发布后，必须要把对应的版本进行打标签，也就是在tags创建对应的tag.7.4.在接受到新的需求或者bugfixed时候，要先确定该功能需求，应该在那个版本上开发，是否需要建立新的分支。7.5.为了降低合并的冲突，在低版本修复bug时，开发员修复一个bug，就合并到对应的高版本，以减少后期合并的冲突发生。
