svn源代码管理规范.doc

《svn源代码管理规范.doc》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、SVN源代码管理规范拟制柏立亚口期2012-9-14审核丨1期yyyy-mm-dd批准口期yyyy-mm-ddRevisionrecord修订记录Date口期Revisionversion修订版本Description修订描述Author作者2012-9-14V1.0初稿形成柏立亚TOD3698DistributionList分发记录CopyNo.Holder'sName&Role持有考和角色IssueDate分发口期1yyyy-mm-dd2yyyy-mm-dd3yyyy-mm-dd4

2、tative>yyyy-mm-dd5yyyy-mm-ddSVN使用规范1.先更新，再提交SVN更新的原则是要随时更新，随时提交。当完成了「个小功能，能够通过编译并且自己测试之后，谨慎地提交。如果在修改的期间别人也更改了svn的对应文件，那么commit就可能会失败。如果别人和自己更改的是同一个文件，那么upckite时会自动进行合并，如果修改的是同一•行，那么合并时会产生冲突，这种情况就需耍同Z前的开发人员联系，两个人一•起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。在更新吋注意所更新文件的列表，如果提交过程屮产生了更新，则也是需耍重

3、新编译并且完成自己的一些必要测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免SVN合并错误导致代码有错。2.一个提交尽量对应一个逻辑问题一次提交多个问题的修改或者一次提交多个模块的不同改动是不被允许的，这样也就失去了版本管理的意义。我们要尽量做到一次提交对应一个问题，涉及一个模块。如果某次修改必须涉及到多个模块，请滦慎检查代码和库上的代码情况，确保不会因为你的上传导致无法回退。3.多提交每次提交的间歇尽可能地短，以几个小时的开发工作为宜。例如在更改UI界面的吋候，可以每完成一个UI界面的修改或者设计，就提交一-次。在开发功能模块的吋候，可以每完成一个小细节功能的测试，就提交一

4、次，在修改bL增的时候，每修改掉一个bug并且确认修改了这个bug,也就提交一次。我们提倡多提交，也就能多为代码添加上保险。1.不要提交不能通过编译的代码代码在提交Z前，首先耍确认白己能够在本地编译。如果在代码屮使用了第三方类库，要考虑到项FI组成员屮有些成员可能没有安装相应的第三方类库。项1=1经理在准备项1=1工作区域的吋候，需要考虑到这样的情况，确保开发小组成员在签出代码之后能够在统一的环境屮进行编译。2.每次提交必须书写明晰的标注在一个项h组屮使用svn,如果提交空的标注或者不确切的标注将会让项n组屮其他的成员感到很无奈，项h经理无法很清晰的掌握丁作进度，无法清晰的把握此次提交的概

5、要信息。在发现错误后也无法准确的定位引起错误的文件。所以，在提交工作吋，要填写明晰的标注，能够概要的描述所提交文件的信息，让项H组其他成员在看到标注后不用详细看代码就能了解你所做的修改。3.对于不同类型的提交需要使用不同类型的前缀作为标记删除某个文件增加文件+:修改文件解决BUG,需要加上fixbug：BUGID4.提交时注意不要提交本地自动生成的文件例如eclipse屮的.classpath文件，Windows生成的缩略图Thumbs.db,项Fl编译生成的临吋文件.obj,.class等等。如果项H屮没有进行这方面的配置來强行禁止提交这样的文件，请自觉不要提交这样的文件。提交了这样的文

6、件后，别人在更新后就可能与本地的环境冲突从而影响人家的工作。8・不要提交自己不明白的代码代码在提交入SVNZ后，你的代码将被项H成员所分亨。如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项H质量的隐患。因此在引入任何第三方代码Z前，确保你对这个代码有-•个很清晰的了解。9.慎用锁定功能在项H小要慎用锁定的功能，在你锁定了一个文件Z后别人就无法继续修改提交该文件，虽然可以减少冲突的发牛率，但是可能会影响项FI组屮其他人员的工作。平吋只有在编辑那些龙法合并的文件（例如图片文件，fkish文件等）吋,才适半的采用锁定操作。10.使用TAG功能为release版本做

7、标记用ReleaseTags标记你版本发布点'的代码。ReleaseTag永远是相应发布分支的副本。ReleaseTag命名规则：“REL・”前缀加上版本号。