开发部SVN使用规范.doc

XXXX股份有限公司开发部SVN使用规范拟制日期审核日期批准日期1、目的：本制度为研发部SVN配置管理的准则和依据，所有与SVN配置管理的行为都必须遵照并服从于本制度。2、适用范围：本制度适用于研发部全体员工。3、名词： 配置管理：是指对项目生存期过程中的各阶段产品和最终产品演化和变更的管理。 变更控制组：是配置项变更的监管组织。 配置项：指哪些应该纳入配置管理之下，成为受控的工作产品最小单位项。 基线：基线是经过正式评审和认可，作为后续工作依据的配置项集合。 配置审计：配置审计主要是验证配置项的完整性和配置项的一致性。4、职责：3.1变更控制组 批准建立基线和标识配置项。 批准基线的发布。 评审与批准基线的更改。 批准由基线库生成产品。3.2项目经理 协助配置管理员制定配置管理计划。 定义基线和配置项。 提出发布申请。 推动项目的配置管理工作。3.3项目组成员 提交配置项内容。3.4配置管理员 制定和维护配置管理计划。 建立和维护配置管理系统。 标识配置项。 发布基线。 执行基线审计。 标识、保存并分发配置状态报告。 从基线库发布产品。3.5质量保证人员（QA） 按照计划和过程检查配置管理活动及其工作产品。 报告检查中发现的问题，追踪问题直至关闭。5、控制要求和方法：5.1 操作流程WorkingCopyWorkingCopyRepositoryNetwork版本库网络本地工作副本检出、提交 首先用户从版本库通过网络“检出”到本地工作副本中，然后，在本地工作副本中进行增加、修改、删除文件后“提交”到版本库中，如果本地工作副本中版本较系统版本过时，用户使用“更新”功能与系统上版本保持一致。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. 不要提交不能通过编译的代码。代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库。14. 提交时注意不要提交本地自动生成的文件，提交的文件必须是开发者共用的程序文件，程序编译中产生的中间文件或文件夹，如/Debug/、/Release/、*.ncb、*.obj、*.o、Thumbs.db、/build/、*.cl