《用SVN分支管理多版本》由会员分享，可在线阅读，更多相关《用SVN分支管理多版本（10页珍藏版）》请在金锄头文库上搜索。
1、用SVN分支管理多版本2010-02-22 梁军1. 目的为了在多个版本中并行开发，提高开发效率，保证各个版本和各 个环境（开发、测试、主干）的独立，避免相互影响，减少最终 发布时合并主干出现冲突的概率，降低冲突处理的难度，特编写 该文档；2. 原则多个版本（开发版本，测试版本，发布版本）；多次合并。3. Svn目录结构采用类似下面的目录结构：projecttrunk+ I+main.js （3.0版本的最新文件）+common.js+branches+I+rl.O4-+I+_imain.js （1.x版本的最新文件）+comm on.js+r2.0+1+ main.js （2.x版本的最新文
2、件）+common.js+ tags （此目录只读）I+ rl.O+I+Hmain.js （1.0版本的发布文件）+common.js+ rl.l+I+Hmain.js （1.1版本的发布文件）+common.js+-rl.2+I+hmain.js （1.2版本的发布文件）+common.js+- rl.3+I+-main.js （1.3版本的发布文件）+comm on.js4-+ r2.0+I+main.js （2.0版本的发布文件）+com mon.js+r2.1I+ main.js （2.1版本的发布文件）+common.jstrunk：主干，是口常开发进行的地方。branches：分支
3、。一些阶段性的release版本，这些版本是可以继续进行 开发和维护的，则放在branches目录中，里面的版本全部基于trunk基础 上建立的。tags：表示标签存放的目录，一般为只读写，存储阶段行发布版本，一般是 基于分支上建立。4. 流程4.1. 选定一个非常稳定的版本作为一个基础版本，也就是主干版本。要求该版本必须是稳定版本。（假设这个版本是1.0）,则当前冃录 结构为：project + trunk+I+main.js （1.0版本的最新文件）+common.jsches+tags4.2. 1.0版本开发完成并已发布，则直接在tags里面打个标签，并且 新需求在主干上开发，此时主干版
4、本变成2.0。则冃录结果变成:projectItrunk+I+main.js（2.0版本的最新文件）+common.js+bra nches+tags+tag.release 1.0 （从主干复制过來，该版本和外网一致）4.3. 如果发现外网版本1.0,有bug,或者有个新的需求，要基于在外 网版本上开发，因为主干版本已和外网不一样，因此不能够在主 干上直接开发，此时，在tag_release 1.0基础上建立一个分支，进 行fixed bug或小功能需求开发，则目录结果为：projectI+ trunk+I+main.js（2.0版本的最新文件）+comm on.js+bra nches+
5、+dev_1.0_fixedBug （从 tag_release 1.0复制过來）+tags+tag_release 1.04.4. 在dev_1.0_fixedBug版本上进行fixed bug,或者在这个基础上进行部分小功能开发，在主干truck进行2.0开发；4.5. dev_1.0_fixedBug版本开发完毕，并正式上线，然后基于dev_1.0_fixedBug的基础上在tags里面打上标签tag,此时目录结果 为：projectI+ trunk+I+main.js （2.0版本的最新文件）+comm on.js+bra nches+dev_1.0_fixedBug+tags+tag
6、_release 1.0+tag_release 1.1 （从 dev_1.0_fixedBug 复制过來）46根据需要选择性地把dev_1.0_fixedBug这个分支合并到主干truck合并原则：低版本合并到高版本：换言之，低版本里面修改的bug, 定 要合并到高版本中。这里的合并可以根据具体来定，如果是bug fixed, 则一定要合并到主干truck中，但如果是小需求修改，并且不计划在后续 版本中实现，则可以不合并相应代码。至于合并时间间隔问题，最长不能 够超过一个礼拜，否则会引起冲突严重，加大合并难度。4.7.当主干上的2.0开发已经结束，进入测试阶段，此时可以规划下一个版本3.0,
7、则在当前主干truck 建立一个分支，目录结果为：projectI+ trunk+I+main.js （3.0版本的最新文件）+common.js+bran ches+dev_1.0_fixedBug+dev_2.0_testing （从原來主干上2.0的版本基础上复制）+taa release 1.04.8.4.8.4.9.4.9.此时在主干上开发3.0,在dev_2.0_testing上fixed bugs。后面步骤类似44-4.7的步骤；如果在2.0 fixed bugs和3.0版本同时进行阶段，想规划下一个版 本4.0,则可以考虑在3.0基础上再做一个分支，为了减少在4.0 版本上的合
8、并，要求4.0版本的需求是属于新增功能，不能够对 原来的文件有过多的修改，否则会引起代码冲突严重。project+ trunk+I+main.js+common.js+dialog.js （因为新增功能而增加的文件40）+b ranches+dev_1.0_fixedBug+dev_2.0_testing+dev_3.0 （从原來主干上3.0的版本基础上复制）+tags+tag_release 1.0+tag_release 1.14.10. 2.0测试，3.0开发、4.0开发多个版本同时进行。5. 优点和不足优点主要有：仁 多个版本相互独立，互不影响2、通过分支与主干的合并，这样主干永远是最
9、新、最高版本，并 且都在后面的测试中，保证了质量。不足当版本比较多时候，低版本上的bug修改，需要合并到高版本， 版本越多，合并的次数就越多。6. 分支合并：6.1. 使用BCompare手工合并；6.2. 使用svn合并功能合并7. 建议7.1. 如果项目的周期比较长，和主干进行合并的次数也应该加大，以 降低处理冲突的难度。7.2. 要求开发人员养成增加注释(log)习惯，方便后期对代码修改的跟 踪。建议svn配置成强制添加注释，方可以提交代码。注释主要 有下面类型：7.2.1. 新增功能：用功能需求作为注释，可以概括为简单的一句话。7.2.2. fixed bug:用bug的标题、ul作为注释；7.2.3. 合并：必须要描述清楚合并来源eg: merge from dev_1.0_fixedBug branch.7.3. 每次发布后，必须要把对应的版本进行打标签，也就是在tags 创建对应的tag.74在接受到新的需求或者bug fixed时候，要先确定该功能需求, 应该在那个版本上开发，是否需要建立新的分支。75为了降低合并的冲突，在低版本修复bug时，开发员修复一个 bug,就合并到对应的高版本，以减少后期合并的冲突发牛。
