svn提交注释规范Word下载.docx
- 文档编号:18837341
- 上传时间:2023-01-01
- 格式:DOCX
- 页数:6
- 大小:17.82KB
svn提交注释规范Word下载.docx
《svn提交注释规范Word下载.docx》由会员分享,可在线阅读,更多相关《svn提交注释规范Word下载.docx(6页珍藏版)》请在冰豆网上搜索。
1.sVn更新的原则是要随时更新,随时提交。
当完成了一个小功能,能够通过编译并且自己测试之后,谨慎地提交。
2.如果在修改的期间别人也更改了svn的对应文件,那么commit就可能会失败。
如果别人和自己更改的是同一个文件,那么update时会自动进行合并,如果修改的是同一行,那么合并时会产生冲突,这种情况就需要同之前的开发人员联系,两个人一起协商解决冲突,解决冲突之后,需要两人一起测试保证解决冲突之后,程序不会影响其他功能。
3.在更新时注意所更新文件的列表,如果提交过程中产生了更新,则也是需要重新编译并且完成自己的一些必要测试,再进行提交。
这样既能了解别人修改了哪些文件,同时也能避免sVn合并错误导致代码有错
二.保持原子性的提交
每次提交的间歇尽可能地短,以几个小时的开发工作为宜。
例如在更改ui界面的时候,可以每完成一个ui界面的修改或者设计,就提交一次。
在开发功能模块的时候,可以每完成一个小细节功能的测试,就提交一次,在修改bug的时候,每修改掉一个bug并且确认修改了这个bug,也就提交一次。
我们提倡多提交,也就能多为代码添加上保险。
三.提交时注意不要提交本地自动生成的文件
一般配置管理员都会将项目中一些自动生成的文件或者与本地配置环境有关的文件屏蔽提交(例如eclipse中的.classpath文件等)。
如果项目中没有进行这方面的配置来强行禁止提交这样的文件,请自觉不要提交这样的文件。
提交了这样的文件后,别人在更新后就可能与本地的环境冲突从而影响大家的工作。
四.不要提交不能通过编译的代码
代码在提交之前,首先要确认自己能够在本地编译。
如果在代码中使用了第三方类库,要考虑到项目组成员中有些成员可能没有安装相应的第三方类库。
项目经理在准备项目工作区域的时候,需要考虑到这样的情况,确保开发小组成员在签出代码之后能够在统一的环境中进行编译。
五.不要提交自己不明白的代码
代码在提交入sVn之后,你的代码将被项目成员所分享。
如果提交了你不明白的代码,你看不懂,别人也看不懂,如果在以后出现了问题将会成为项目质量的隐患。
因此在引入任何第三方代码之前,确保你对这个代码有一个很清晰的了解。
六.提前协调好项目组成员的工作计划
项目经理应该合理分配工作计划。
每个成员在准备开始进行某项功能的修改之前,如果有可能,先跟工作小组的成员谈谈自己的修改计划,让大家都能了解你的思想,了解你即将对软件作出的修改,这样能尽可能的减少在开发过程中可能出现的冲突,提高开发效率。
同时你也能够在和成员的交流中发现自己之前设计的不足,完善你的设计。
七.对提交的信息采用明晰的标注(写注释)
在一个项目组中使用sVn,如果提交空的标注或者不确切的标注将会让项目组中其他的成员感到很无奈,项目经理无法很清晰的掌握工作进度,无法清晰的把握此次提交的概要信息。
在发现错误后也无法准确的定位引起错误的文件。
所以,在提交工作时,要填写明晰的标注,能够概要的描述所提交文件的信息,让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。
八.慎用锁定功能
在项目中要慎用锁定的功能,在你锁定了一个文件之后别人就无法继续修改提交该文件,虽然可以减少冲突的发生率,但是可能会影响项目组中其他人员的工作。
平时只有在编辑那些无法合并的文件(例如图片文件,flash文件等)时,才适当的采用锁定操作。
篇二:
sVn版本管理,提交代码规范
篇三:
开发部sVn使用规范
xxxx股份有限公司
开发部sVn使用规范
1、目的:
本制度为研发部sVn配置管理的准则和依据,所有与sVn配置管理的行为都必须遵照并服从于本制度。
2、适用范围:
本制度适用于研发部全体员工。
3、名词:
配置管理:
是指对项目生存期过程中的各阶段产品和最终产品演化和变更的管理。
变更控制组:
是配置项变更的监管组织。
配置项:
指哪些应该纳入配置管理之下,成为受控的工作产品最小单位项。
基线:
基线是经过正式评审和认可,作为后续工作依据的配置项集合。
配置审计:
配置审计主要是验证配置项的完整性和配置项的一致性。
4、职责:
3.1变更控制组
批准建立基线和标识配置项。
批准基线的发布。
评审与批准基线的更改。
批准由基线库生成产品。
3.2项目经理
协助配置管理员制定配置管理计划。
定义基线和配置项。
提出发布申请。
推动项目的配置管理工作。
3.3项目组成员
提交配置项内容。
3.4配置管理员
制定和维护配置管理计划。
建立和维护配置管理系统。
标识配置项。
发布基线。
执行基线审计。
标识、保存并分发配置状态报告。
从基线库发布产品。
3.5质量保证人员(qa)
按照计划和过程检查配置管理活动及其工作产品。
报告检查中发现的问题,追踪问题直
至关闭。
5、控制要求和方法:
5.1操作流程
版本库
本地工作副本
首先用户从版本库通过网络“检出”到本地工作副本中,然后,在本地工作副本中进行增加、修改、删除文件后“提交”到版本库中,如果本地工作副本中版本较系统版本过时,用户使用“更新”功能与系统上版本保持一致。
5.2帐号注册、权限申请
1.用户帐号注册:
新进员工没有sVn帐号,通过邮件联系sVn管理员,邮件正文注明
申请sVn普通帐号,管理员处理完帐号注册事宜后,会邮件回复。
注:
普通帐号,只对个人目录有读取权限。
2.权限的申请:
根据员工所参与的项目,sVn管理员对其开放相应目录的读、写权限。
3.账号注销:
员工离职后,对其账号进行注销。
5.2操作规范
1.每日进行开发工作之前更新代码,下班时提交代码。
2.各员工需牢记各自的账户和密码,不得向他人透漏,严禁使用他人账户进行sVn各项
操作。
3.不要签出整个目录,除非特别必要,不应同时签出过多的项。
4.文件提交时要求必须提交注释,注明相关修改信息,日志信息描述的越详细越好,让项
目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。
5.代码变动及时提交,避免丢失本地修改后无法恢复。
6.在提交之前要编译代码并修正错误。
要保证新增加的文件同时被提交,否则只在你本地
能正常工作,导致其它人不能编译通过。
7.提交之前要测试所改变的应用,测试改变后的效果是否达到预期的目的。
8.多次检查提交的内容。
提交之前应先做sVn更新或与资源库同步,注意到sVn关于冲
突、错误的信息。
资源库同步会告诉你将要提交的内容与资源库内容之间的差别,确认它们是不是你真正想要提交的。
9.如果别人和自己更改的是同一个文件,那么update时会自动进行合并,如果修改的是
同一行,那么合并时会产生冲突,这种情况就需要同之前的开发人员联系,两个人一起协商解决冲突,解决冲突之后,需要两人一起测试保证解决冲突之后,程序不会影响其他功能。
10.在更新时注意所更新文件的列表,如果提交过程中产生了更新,则也是需要重新编译并
且完成自己的一些必要测试,再进行提交。
这样既能了解别人修改了哪些文件,同时也能避免sVn合并错误导致代码有错。
11.提前宣布修改计划。
当你计划进行修改,需要影响到sVn里的许多文件时,先通过邮
件或者当面通知其他开发者。
例如,修改底层数据库模块时,有可能影响到业务逻辑层调用数据库模块的地方。
这样其他开发者会有准备,也会对修改提出意见和建议。
12.每次提交尽量是一个最小粒度的修改。
比如一个小功能提交一次。
13.不要提交不能通过编译的代码。
代码在提交之前,首先要确认自己能够在本地编译。
如
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- svn 提交 注释 规范