1 / 3
文档名称:

SVN版本管理与提交代码规范.doc

格式:doc   大小:31KB   页数:3页
下载后只包含 1 个 DOC 格式的文档,没有任何的图纸或源代码,查看文件列表

如果您已付费下载过本站文档,您可以点这里二次下载

分享

预览

SVN版本管理与提交代码规范.doc

上传人:2072510724 2019/10/31 文件大小:31 KB

下载得到文件列表

SVN版本管理与提交代码规范.doc

文档介绍

文档介绍:SVN版本管理,提交代码规范项目开发要求: 1、工作目录要及时更新,不要和SVN服务器有太大的差别2、提交代码时,如果出现冲突,必须仔细分析解决,不可以强行提交3、提交代码之前先在本地进行测试,确保项目能编译通过,且能够正常运行,不可盲目提交4、必须保证SVN上的版本是正确的,项目有错误时,不要进行提交 SVN注意事项,请严格按照操作顺序操作,避免提交代码导致重大事故:.   SVN更新的原则是要随时更新,随时提交。当完成了一个小功能,能够通过编译并且自己 测试 之后,谨慎地提交。2.     如果在修改的期间别人也更改了svn的对应文件,mit就可能会失败。如果别人和自己更改的是同一个文件,那么update时会自动进行合并,如果修改的是同一行,那么合并时会产生冲突,这种情况就需要同之前的开发人员联系,两个人一起协商解决冲突,解决冲突之后,需要两人一起测试保证解决冲突 之后,程序不会影响其他功能。3.     在更新时注意所更新文件的列表,如果提交过程中产生了更新,则也是需要重新编译并且完成自己的一些必要测试,再进行提交。这样既能了解别人修改了哪些文件,,以几个小时的开发工作为宜。例如在更改UI界面的时候,可以每完成一个UI界面的修改或者设计,就提交一次。在开发功能模块的时候,可以每完成一个小细节功能的测试,就提交一次,在修改bug的时候,每修改掉一个bug并且确认修改了这个bug,也就提交一次。我们提倡多提交,也就能多为代码添加上保险。()。如果项目中没有进行这方面的配置来强行禁止提交这样的文件,请自觉不要提交这样的文件。提交了这样的文件后,别人在更新后就可能与本地的环境冲突从而影响大家的工作。,首先要确认自己能够在本地编译。如果在代码中使用了第三方类库,要考虑到项目组成员中有些成员可能没有安装相应的第三方类库。项目经理在准备项目工作区域的时候,需要考虑到这样的情况,确保开发小组成员在签出代码之后能够在统一的环境中进行编译。,你的代码将被项目成员所分享。如果提交了你不明白的代码,你看不懂,别人也看不懂,如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前,确保你对这个代码有一个很清晰的了解。