SVN源代码管理规范精

1、1i:CDYWsoftSVN源代码管理规范i>n7 s I吕HL n)nvSVN简述、E '-rlTX Subversion是一种集中的分享信息的系统，它 的核心是版本库，储静所有的数据，版本库按 照文件树形式储存数据一包括文件和目录，任 意数量的客户端可以连接到版本库，读写这些 文件。通过写数据，别人可以看到这些信息； 通过读数据，可以看到别人的修改。M Subversion会记录每一次的更改，不仅针对文 件也包括目录本身，包括增加、删除和重新组 织文件和目录SVN版本库结构X TrunkX BranchesX TagsTRUNKX任何时候Trunk里包含的都是最新开发代码。这

2、里的 代码将会工作到你的下一个主要发布版本。X据我所见，几乎常常人们只使用trunk来存放他们的 代码。发放了一个版本后继续在其上进行下一版开 发。这不好，无论是对你还是你的产品。X Trunk应该只被用来开发将会成为你的下一个重要版 本的代码。不要给trunk加上版本号和发布名称。仅 需要保证trunk在任何时候都处于“开发模式” OBRANCHES Release Branches Bug fix branches Experimental branchesRELEASE BRANCHES当trunk达到准备发布的阶段时（或者你想冻结新特色 的添加时），你应该创建一个release bra

3、nches。 Release branches只是彳尔当前trunk的一个副本o这类branches可 以被单独签出 你也可 以启动branches 和基于此版本的项目。你还可以使用此分支在测试期 间修复Bug。这种方式能够保证trunk继续开发，而不 会被发布某个具体的版本所干扰。因此当你准备发布 一个祈版未0,这屛不会影徐trunk增加薪殆功能。 命名方式：RB-X.XXBUG FIX BRANCHES分支也可以用 于处理trunk或release brarches里发现的严重 的Bug。当某些Bug很复杂，你不能通过只提交一次就修复他 们。因此为了集中精力修正此错误，你应该为此问题创建一

4、 个新的分io这样就木会影响trunk和release branches斫继 续进行，并且你也不会因为发现渤的Bug和测试而干扰此 Bug的修复。Bug修复分支的命名通常遵循下列方式：使用你的缺陷管理 系统分配给此Bug的ID。通常这是一个数字Q如：Bug-3391o当然，你也可以象其它分支一样访问你的Bug分支。EXPERIMENTAL BRANCHES有时你想将某个新技术引进项目。这很好，但是你当然不想 赌上你的整个项目。想象一下，你想把你的Web程序从PHP4 改为PHP5o你耍花多少时间？在这期间你的trunk停止使用？ ft到你把所有到PHP5的转换做完！这是实验，可能PHP5就像彩

5、虹的另一端一样离你的程序太远 了，你应该给他创建一个分支。你可以在分支里进行更改， 如采失败了，你在当前分支仍然有PHP4的代码。如采失败了，实验分支可以抛弃。如采成功，你可以很容易 的蒋套合并到trunk并继续你的新技术0卖恣分支裕名遵循汪 面原则：为其名字加上前缀“TRY/ OXTAGSX标签就像分支一样备份你的代码。但是 Tag不被用来开发，他们只是用来标记你 代码的状态OTAGSX标签就像分支一样备份你的代码。但是 Tag不被用来开发，他们只是用来标记你 代码的状态。 Release tags Bug fix PRE and POST tagsRELEASE TAGSM Release

6、 Tags标记你版本发布点的代码。 Release Tag永远是相应发布分支的副本。 Release Tagx命名规则：“RELZ 前缀加上版本号。BUG FIX PRE AND POST TAGSX当你创建了一个Bug fix分支，你想标记代 码在BugFix之前和之后的状态。这样你就 浪容易的引用你所做的更改，合并到trunk 或Release branches。X命名规则：+ “P RE/ 加上 BugID;+ “POST” 加上Bug ID。SVN使用规范先更新，再提交多提交不要提交不能通过编译的代码 每次提交必须书写明晰的标注提交时注意不要提交本地自动生成的临 时文件不要提交自己不明

7、白的代码 慎用锁定功能先更码珥提交SVN更新的原则是要随时更新，随时提交。当完成了一个 小功能，能够通过编译并且自己测试之后，谨慎地提交。如果在修改的期间别人也更改了svn的对应文件，那么 commit就可能会萸败。如果别人和自 己更改的是向一个文 件，那么update时会自动进行合并，如果修改的是同一行, 那么合并时会产生冲究，这种情况就需要同之前的开发人 员联系，两个人一起协商解决冲突，解决冲突之后，需要 两人一起测试保证解决冲突之后，程序不会彬响其他功能。在更新时注意所更新文件的列表，如果提交过程中产生了 更新，则也是需要重新编译并且完成自己的一些必要测试, 再进行提交。这样既能了解别人

8、修改了哪些文件，同时也 能避免SVN合并错误导致代码有错。X多提交X每次提交的间歇尽可能地短，以几个小 时的开发工作为宜。例如在更改UI界面 的时候，可以每完成一个UI界面的修改 或者设计，就提交一次。在开发功能模 块的时候，可以每完成一个小细节功能 的测试，就提交一次，在修改bug的时 候，每修改掉一个bug并且确认修改了 这个bug,也就提交一次。我们提倡多 提交，也就能多为代码添加上保险。X代码在提交之前，首先要确认自己能够 在本地编译。如果在代码中使用了第三 方类库，要考虑到项目组成员中有些成 员可能没有安装相应的第三方类库。项 目经理在准备项目工作区域的时候，需 要考虑到这样的情况，

9、确保开发小组成 员在签出代码之后能够在统一的环境中 进行编译。每次提交必须书写 明 晰的标注m 小 口eg，：w3c在一个项目组中使用SVN,如果提交空 的标注或者不确切岛标注将会让项目组 中其他的成员感到很无奈，项目经理无 痰很清晰的掌握工作进度，无法清晰的 把握此次提交的概要信息。在发现错误 后也无法准确的定位引起错误的文件。 所以，在提交工作时，要填写明晰的标 注，能够概要的描述所提交文件的信息, 让项目组其他成员在看到标注后不用详 细看代码就能了解你所做的修改。不耍提交本地自动生成的文件M 例如eclipse 中 的.classpath 文件, Windows生成的缩略图Thumbs.db,项目 编译生成的临时文件obj等等。如果项 目中没有进行这方面的配置来强行禁止 提交这样的文件，请自觉不要提交这样 的文件。提交了这样的文件后，别人在 更新后就可能与本地的环境冲突从而影 响大家的工作。不耍提交自己不明白的代码其代码在提交入SVN之后，你的代码将被 项目成员所分享。如果提交了你不明白 的代码，你看不懂，别人也看不懂，如 果在以后出现了问题将会成为项目质量 的隐患。因此在引入任何第三方代码之 前，确保你对这个代码有一个很清晰