《SVN提交规范.docx》由会员分享，可在线阅读，更多相关《SVN提交规范.docx（6页珍藏版）》请在三一办公上搜索。
1、SVN提交规范SVN提交规范 文件编号： 文件编号 生效日期 版本号 SVN提交规范 拟 制: 审 核: 批 准: 第 1 页 共 5页 日期： 日期： 日期： SVN提交规范 文件编号： 修订记录 日期 修订版本 修改描述 作者 第 2 页 共 5页 SVN提交规范 文件编号： 目录 1、规范的目的 . 3 2、术语和定义 . 4 3、适用范围 . 4 4、参考和引用 . 4 5、细则 . 4 6、补充说明 . 5 1、规范的目的 本规范规定在产品开发过程中涉及的代码在SVN上的提交规则，确保分类清晰、提交格式统一、第 3 页 共 5页 SVN提交规范 文件编号： 简洁、便于管理。 2、术语
2、和定义 代码：包括软件开发过程中从开发商获取的源代码、自己开发的代码、针对测试反馈的bug进行修改的代码。 工作目录：软件开发人员本地主机或者编译服务器上，用于调试问题、解决BUG的源代码目录。 编译目录：软件开发人员本地主机或者编译服务器上，用于编译版本、提交代码到SVN的源代码目录。 模块名：为本次提交代码的主要模块名称，采用全大写字母标识，尽量与程序中模块的命名相同，且前后应保持一致，不应同一模块出现多种不同的命名方式。 3、适用范围 本规范适用于规范研发体系所有软件工程师的SVN提交。 4、参考和引用 5、细则 5.1 SVN注释 SVN的提交时对注释的规范： 1、 注释文字可以使用中
3、文或英文，推荐使用中文，要求都能清晰表述要表达的意思 2、 注释说明符合要求的格式以及内容完整，包括如下的内容： 格式要求：注释包括2个部分，中间用“ | ”隔开，第一个部分描述操作的类别；第二部分对该操作的目的、方法、可能的注意事项进行描述。第一部分的第一个词为类别关键词，具体分类和关键词如下： Vendor：供应商提供的原始代码加入SVN进行受控管理 Develop：支持新特性的开发提交代码，包括功能优化和性能提升等的相关开发工作 Bug：开发阶段完成后，各测试环节反馈的问题修改，包括测试部、现场、工厂等 Customize：客制化需求软件制作过程中代码的修改 内容完整要求：SVN提交时必
4、须说明该操作的目的，并尽可能的对相关的实现方法或注意事项进行说明；要尽量详细、清晰的说明修改内容，不允许为空或仅使用“Fix、Mofidy”等简单字词进行备注； 其他要求：为便于检索、跟踪，推荐在注释的内容中尽可能多的包括功能特性相关的模块或特性名称 5.2 SVN提交要求 代码的提交遵循如下的规则： 1、 供应商提供的代码：需在代码提交时注明对应的供应商，以及该代码支持的硬件情况进行第 4 页 共 5页 SVN提交规范 文件编号： 说明，并尽可能对重点特性简要说明，如“11n”、“WAPI” svn m “Vendor: Broadcom | 注释” 2、新特性的开发提交的代码：是指开发阶段
5、的代码提交，提交要详细注明特性要求，设计或实现的大体原理，相关的注意事项，包括遗留问题等。可在Develop后面写上新特性的关键词，也可不写 svn m “Develop | 模块名 + 注释” 3、问题修改的代码提交：提交中需写明对应的bugFree编号，并对问题简要描述、问题的解决方法简要描述，同时要说明注意事项 svn m “Bug: xxxxxxx, xxxxxxx, | 模块名 + 注释” 其中xxxxxxx为对应的BugFree编号；如果一处修改同时改好多个bug，则同时写上多个BugFree编号。 要求修改一个bug，提交一次，禁止将几个可分开的问题修改合并在一起提交。 4、 客
6、制化代码提交：提交中需写明对应的客户、出货的地点；并对客户的主要需求做简要说明。有的客制化也会涉及客户提到的新特性要求，则新特性的实现按第2点进行单独提交。 svn m “Customize | 注释” 5、 禁止代码的随意更改，对一个特定项目，不允许改动一个问题，分多次提交SVN 对于注释，参照5.1的规范要求 5.3 SVN提交流程 针对开发代码提交以及问题修改的代码提交要遵循如下的流程： 1、先在工作目录进行开发、调试、修改 2、同步编译目录的代码到SVN服务器上的最新版本 3、将本次要提交的修改内容从工作目录合入到编译目录 4、编译目标代码并进行验证测试 5、将改动内容合入到SVN 6、从SVN重新下载包含本次改动的代码，进行编译、验证 其他要求： 1、工作目录也要及时更新，不要和SVN服务器有太大的差别 2、提交代码时，如果出现冲突，必须仔细分析解决，不可以强行提交 6、补充说明 1. SVN提交过程中涉及的其他内容，参阅公司相关发布文件。 第 5 页 共 5页
