代码审查规范
LG GROUP system office room 【LGA16H-LGYY-LGUA8Q8-LGA162】
代码审查规范
1. Code Review目的
Code Review是一种用来确认方案设计和代码实现的质量保证机制，通过这个机制我们可以对代码、测试过程和注释进行检查。
Code Review主要用来在软件工程过程中改进代码质量，通过Code Review可以达到如下目的：在项目早期就能够发现代码中的BUG。
帮助初级开发人员学习高级开发人员的经验，达到知识共享。
避免开发人员犯一些很常见，很普通的错误。
保证项目组人员的良好沟通。
项目或产品的代码更容易维护。
2. Code Review的前提条件
代码提交审核前，开发者必须确保代码符合如下条件，审核者需要确保所有前提条件都已满足方可开始审查，同时也是审查的主要检查点。
所有代码注释清晰，语法正确，编译通过。
日志代码完整，业务日志、系统日志分开，中文描述，脱敏处理，状态变更，全部清晰明确。
测试代码覆盖全部分支和流程，暂时统一使用工具Emma（各编译器可下载对应插件）进行Coverage Check。
项目引用关系明确，依赖关系清晰，配置文件描述。
3. Code Review的审查范围
代码的一致性、编码风格、代码的安全问题、脱敏问题、代码冗余、是否正确设计以符合设计要求（性能、功能）与设计文档相同等等。
、完整性检查（Completeness）
代码是否完全实现了设计文档中所涉及的所有流程和功能点
代码是否已包含所有所需的业务日志、系统日志、异常日志，日志内容是否完整，日志文件配置是否正确。
代码是否使用缓存等，配置信息是否正确可配置。
代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型等
、一致性检查（Consistency）
代码的逻辑是否符合设计文档
代码中使用的格式、符号、结构等风格是否保持一致
、正确性检查（Correctness）
代码是否符合制定的标准
所有的变量都被正确定义和使用
所有的注释都是准确的
所有的程序调用都使用了正确的参数个数
、可修改性检查（Modifiability）
代码涉及到的常量是否易于修改(如使用配置、定义为类常量、使用专门的常量类等)
代码中是否包含了交叉说明或数据字典，以描述程序是如何对变量和常量进行访问的
代码是否只有一个出口和一个入口（严重的异常处理除外）
、可预测性检查（Predictability）
代码所用的开发语言是否具有定义良好的语法和语义
是否代码避免了依赖于开发语言缺省提供的功能
代码是否无意中陷入了死循环
代码是否避免了无穷递归
、健壮性检查（Robustness）
代码是否采取措施避免运行时错误（如数组边界溢出、被零除、值越界、堆栈溢出等）、结构性检查（Structuredness）
程序的每个功能是否都作为一个可辩识的代码块存在
循环是否只有一个入口
、可追溯性检查（Traceability）
代码是否对每个程序进行了唯一标识
是否有一个交叉引用的框架可以用来在代码和开发文档之间相互对应
代码是否包括一个修订历史记录，记录中对代码的修改和原因都有记录
是否所有的安全功能都有标识
、可理解性检查（Understandability）
注释是否足够清晰的描述每个子程序
是否使用到不明确或不必要的复杂代码，它们是否被清楚的注释
使用一些统一的格式化技巧（如缩进、空白等）用来增强代码的清晰度
是否在定义命名规则时采用了便于记忆，反映类型等方法
每个变量都定义了合法的取值范围
代码中的算法是否符合开发文档中描述的数学模型
、可验证性检查(Verifiability)
代码中的实现技术是否便于测试
测试代码是否正确，是否覆盖所有流程
4. Code Review的步骤
目前Code Review 步骤暂定如下，试行一段时间再根据问题做调整。
1.代码编写者和代码审核者坐在一起，由代码编写者按照设计文档中的用例依次讲解自己
所写的代码和相关逻辑，可采用从前端到后台的方式，例如从Web层->DAO层。
2.代码审核者在此过程中可以随时提出自己的疑问，同时积极发现隐藏的bug；代码编写
者和代码审核者都要对这些bug记录在案，代码编写者修改后再次提交审核，代码审核者对应bug记录进行回验。
3.代码讲解完毕后，代码审核者给自己安排几个小时再对代码审核一遍。
4.代码需要一行一行静下心看。同时代码又要全面的看，以确保代码整体上设计优良。
5.代码审核者根据审核的结果编写代码“审核结果”并将“审核记录”和“审核结果”提
交至GIT，审核记录和审核结果参见附录I 审核记录、附录II 审核结果。
6.代码编写者GIT pull并根据“审核结果”给出的修改意见，修改好代码，有不清楚的
地方可积极向代码审核者提出。
7.代码编写者bug fix等全部修改完成后提交代码审核者再次进行审核，通过审核则代码
审核者更新本次审查结果并提交至GIT，审核通过对代码不能再进行修改，任何已通过审核的代码修改必须重新进行审核流程。
8.代码审核者把Code Review中发现的有价值的问题更新到"代码规范"的文档中，对于特
别值得提醒的问题可群发email或QQ给所有技术人员。
5. Code Review 标准
代码审查的基础是我们的设计文档规范、代码规范、日志规范、测试代码规范，针对新增的业务场景和设计尚未有规范对应时应先确立规范然后再进行代码审核流程。
6. Code Review 注意点
. 经常进行Code Review
要Review的代码越多，那么要重构，重写的代码就会越多。而越不被代码编写者接受的建议也会越多，唾沫口水战也会越多。建议每一个功能，每一个用例完成后都可以进行审核，将大任务拆分为小任务进行。
程序员代码写得时候越长，程序员就会在代码中加入越来越多的个人的东西。
越接近软件发布的最终期限，代码也就不能改得太多。
. Code Review不要太正式，而且要短
忘了那个代码评审的Checklist吧，走到你的同事座位跟前，像请师父一样请他坐到你的电脑面前，然后，花5分钟给他讲讲你的代码，给他另外一个5分钟让他给你的代码提提意见，这比什么都好。而如果你用了一个Checklist，让这个事情表现得很正式的话，下面两件事中必有一件事会发生：
只有在Checklist上存在的东西才会被Review。
Code Reviews 变成了一种礼节性的东西，你的同事会装做很关心你的代码，但其实他心里想着尽快地离开你。只有不正式的Code Review才会让你和评审者放轻松，人只有放松了，才会表现得很真实，很真诚。记住Review只不过是一种形式，而只有在相互信任中通过相互的讨论得到了有意义和有建设性的建议和意见，那才是最实在的。不然，作者和评审者的关系就会变成小偷和警察的关系。
. 尽可能的让不同的人Reivew你的代码
如果可能的话，不要总是只找一个人来Review你的代码，不同的人有不同的思考方式，有不同的见解，所以，不同的人可以全面的从各个方面评论你的代码。但不要太多了，人多嘴杂反而适得其反，基本上来说，不要超过3个人，这是因为，这是一个可以围在一起讨论的最大人员尺寸。
下面是几个优点：
从不同的方向评审代码总是好的。
会有更多的人帮你在日后维护你的代码。
这也是一个增加团队凝聚力的方法。
. 保持积极的正面的态度
程序员最大的问题就是“自负”，尤其当我们Reivew别人的代码的时候，我已经见过无数的场面，程序员在Code Review的时候，开始抨击别人的代码，质疑别人的能力。太可笑了，我分析了一下，这类的程序员其实并没有什么本事，因为他们指责对方的目的是想告诉大家自己有多么的牛，靠这种手段来表现自己的程序员，其实是就是传说中所说的“半瓶水”。所以，无论是代码编写者，还是代码审核者，都需要一种积极向上的正面的态度，编写者需要能够虚心接受别人的建议，因为别人的建议是为了让你做得更好；审核者也需要以一种积极的正面的态度向编写者提意见，因为那是和你在一个战壕里的战友。记住，你不是一段代码，你是一个人！
. 学会享受Code Reivew
这可能是最重要的一个提示了，如果你到了一个人人都喜欢Code Reivew的团队，那么，你会进入到一个生机勃勃的地方，在那里，每个人都能写出质量非常好的代码，在那里，你不需要经理的管理，团队会自适应一切变化，他们相互学习，相互帮助，不仅仅是写出好的代码，而且团队和其中的每个人都会自动进化，最关键的是，这个是一个团队。
7. Code Review操作
目前我们将Code Review 分为两个阶段，开发互审和上级审查两个阶段。
开发互审
任意两名开发人员（建议不要固定配对，避免思维定势）进行交叉代码审查，代码编写者准备所开发的代码相关的全部资料列表，包括需求、设计文档、代码工程、类、方法、配置文件、数据库修改、数据修改等全部资料的版本号等详细信息，向代码审查者全面介绍代码的目标和设计实现。代码审查者按照需求文档、设计文档、开发规范进行代码（业务、日志、测试）审查，代码审查者将审查结果提交至GIT，出现的问题由代码编写者进行修改并由代码审查者复审，复审结果提交至GIT保留。代码审查者对所审查的代码负责。
上级检查
开发互审完成后，由上级进行上级审查，流程与开发互审相同，对于三次复审仍未通过的代码需要代码编写者组内进行检讨问题原因，并书面列出改进计划。
冲突解决
当开发互审时对于检查内容出现争议时由上级进行协调解决或逐级向上协调解决。当上级审查时出现争议时逐级向上协调解决。
所有问题解决原则为公司利益、团队利益、业务需求、设计文档、规范文档等为
参考标准。
附录I 审核记录
审核记录如同修改记录一样，直接记录入代码头部，代码审核者修改审核记录后提交代码至GIT参考即可。之后的审核可以基于两次审核间的变更利用对比工具进行增量审核。可参考如下示例类：ngp_common/src/main/java/com/heepay/file/
代码示例：
附录II 审核结果
审核结果建议以表格的形式描述，每个问题分别列出，可以通过标注行号来具体指明位置，给出合理的修改意见并说明标准。为了方便记录和查询以及代码编写者修改和复审，建议审核结果写入commit message中，由于commit message只能提交文本，我们以软表格的形式描述。对于commit message 的书写规范，查看参考。
格式：
示例：
docs(代码审核):审核失败
1.日志不符合规范问题：没有使用log4j2，日志不规范建议：修改使用log4j2，包括包引用和代码修改行号：53行
2.命名不符合规范问题：log命名不符合规范建议：修改为logger 行号：53行
程序设计综合训练<图书馆管理系统> 设计报告 院系：材料科学与工程学院 专业班级：材料成型一班 姓名：张成智 学号： 20111402128 指导老师：肖老师
一、程序功能简介 图书排序功能 1）按图书编号排序 可以按图书编号的大小排序，显示到屏幕上。（从小到大） 2）按图书出版时间排序 可以按图书出版时间的前后排序，显示到屏幕上。（从近到远） 3）按图书价格排序 可以按图书价格的贵宜排序，显示到屏幕上。（从便宜到贵） 4）按图书书名排序 可以按图书书名字符的大小排序，显示到屏幕上。（从小到大） 5）按图书作者名排序 可以按图书作者名字符的大小排序，显示到屏幕上。（从小到大） 二、本人完成的主要工作 图书排序功能（排序比较简单只要做出来一个，其他都和它雷同。） 三、设计方案 1.设计分析； 1)序功能简介： s 进入系统
|| 2）各个功能流程图 1、按图书编号排序 菜单 1-添加图书 4-图书排序 5-查询图书 6-修改图书 7-录入数据 0-退出系统 2-删除图书 3-图书列表 输入编号、书名、 作者名、出版社、 类别、出版时间、 价格。 按照编号、书名、作者名、出版社、类别、出版时间、 价格进行删除。 按照编号、书名、作者名、出版社、类别、出版时间、 价格进行列出。 按照编号、书名、作者名、出版社、类别、出版时间、 价格进行排列。 按照编号、书名、作者名、出版社、类别、出版时间、 价格进行咨询。 依次录入编号、书名、作者名、出版社、类别、出版时间、 选择编号、书名、作者名、出版社、类别、出版时间、 价格进行修改。 输入0返回原始菜单。
代码走查(code walkthrough)和代码审查(code inspection)是两种不同的代码评审方法, 代码审查是一种正式的评审活动，而代码走查的讨论过程是非正式的。 最近对项目组进行代码评审，发觉需要对代码评审中找到的问题进行一下分类，大概可以分成以下几类问题： 1. Comment 注释没写，或者格式不对，或者毫无意义 2. Coding Standard 没遵守代码规范 3. Existing Wheel 重复现成的代码，或者是开源项目，或者公司已有代码 4. Better practice Java或者开源项目，有更好的写法 5. Performance bottle and Improvement 性能瓶颈和提高 6. Code Logic Error 代码逻辑错误 7. Business Logic Error 业务逻辑错误 代码审查列出问题的类型，并有解决情况报告 11月23日 代码走查——项目走向成功的锦囊之一 说起代码走查，相信每个人都不陌生，但为什么要执行代码走查，什么时候来执行代码走查，如何有效执行代码走查，很多人的看法和见解都不一样。 一般的看法，认为代码走查是一种非正式的代码评审技术，它通常在编码完成之后由代码的作者向一组同事来讲解他自己编写的代码，由同事来给出意见。 这种做法在很多做软件开发组织中经常采用。但从实际执行效果来看，成效并不都那么明显，反而很多组织的这种做法有浪费时间之嫌。主要是因为代码走查活动时间有限，而参加代码走查的人之前没有较多的时间来提前了解被走查的代码，故而在实际执行时能被走查的代码所占的比例并不高，同时也发现不了多少本质问题。 随着软件外包业的发展，它有别于软件产品开发，客户对于产品的要求不再局限于系统是否能够正确运行。而是在设计、代码的品质上也有了更多的要求。有的客户甚至会在我们每次交付后先来检查我们的代码品质，只要是代码不符合要求就会被拒绝。
Git源代码管理规范 一、分支管理 使用git进行源代码管理, 一般将某个项目的所有分支分为以下几条主线: 1.Master 顾名思义, 既然名字叫Master, 那么该分支就是主分支的意思。master分支永远是production-ready的状态, 即稳定可产品化发布的状态。 2.Develop 这个分支就是我们平常开发的一个主要分支了, 不论是要做新的feature还是需要做bug fix, 都是从这个分支分出来做。在这个分支下主要负责记录开发状态下相对稳定的版本, 即完成了某个feature或者修复了某个bug后的开发稳定版本。 3.Feature branches 这是由许多分别负责不同feature开发的分支组成的一个分支系列。new feature主要就在这个分支系列下进行开发。当功能点开发测试完毕之后, 就会合并到develop分支去。
4.release branches 这个分支系列从develop分支出来, 也就是预发分支。在预发状态下, 我们往往会进行预发环境下的测试, 如果出现缺陷, 那么就在该release分支下进行修复, 修复完毕测试经过后, 即分别并入master分支后develop分支, 随后master分支做正常发布。 5.Hotfix branches 这个分支系列也就是我们常说的紧急线上修复, 当线上出现bug且特别紧急的时候, 就能够从master拉出分支到这里进行 修复, 修复完成后分别并入master和develop分支。 下面这张图将完整展示这一个流程
二、工作原理Git的工作方式:
也就是说, 每次提交版本变动的时候, git会保存一个快照(snapshot)。如果文件没有被更改, git也不会再次保存, 而是提供一个到原来文件的链接。这样一来, git更像是一个小型的文件系统。另外, git的所有操作都能够是本地的, 仅仅在将新版本的内容上传到服务器上时才需要连接网络。 Git目录( repository) 是Git保存元数据和对象数据库的地方。这也是Git最重要的部分。
软件版本管理规 第一章目的 本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容，使软件项目版本管理流程化并规化，确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。 2.第三章职责 配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。 此岗位可由开发或测试人员兼任。 3.第四章容 4.1. 版本管理对象 包括但不限于： 项目总体计划 可行性研究报告 开发计划 需求说明书 需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划
上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目部的目录结构建议按下列格式创建。 配置库目录结构规划： ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中，项目部的目录结构： |–projectA |–src （保存该项目的源程序） |–doc （保存项目相关文档） |–000.项目管理（保存项目过程管理相关文档） |–010.项目计划（保存项目计划相关文档） |–020.项目需求（保存项目需求相关文档） |–030.系统设计（保存项目设计相关文档） |–030.系统测试（保存项目代码测试相关文档） |–040.系统实施（保存项目部署实施相关文档） |–050.系统运维（保存项目运维文档，包括培训、用户手册等） |–060.技术资料（保存项目技术文档，包括第三方技术资料等）
变更履历
目录 1总则 (4) 2源代码完整性保障 (4) 3源代码的授权访问 (4) 4代码版本管理 (5) 4.1系统初验 (6) 4.2试运行 (6) 4.3系统终验 (7) 4.4系统验收标准 (7)
1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。 3源代码的授权访问 1、源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。 第十条在SVN库中设置用户，并为不同用户分配不同的，适合工作的最小
1源代码管理 (1) 总则 (1) 源代码完整性保障 (1) 源代码的授权访问 (2) 代码版本管理 (2) 源代码复制和传播 (5) 系统测试验收流程 (5) 系统初验 (6) 试运行 (6) 系统终验 (6) 应用系统验收标准 (8) 文档评审通过标准 (9) 确认测试通过标准 (9) 系统试运行通过标准 (10)
1代码管理 总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。
WATER Corporation 代码走查计划书Version 2.0 XXX 2012/3/20
文档修改记录
目录 1.进度计划 (4) 2.待评审物 (4) 3.成员角色 (5) 4.基本原则 (5) 4.1代码评审原则 (5) 4.2评审指导文档 (6) 5.走查过程定义 (6) 5.1代码走查计划准备阶段 (6) 5.2个人代码走查阶段 (6) 5.3代码走查会议阶段 (7) 5.4缺陷修改与关闭 (7)
1.进度计划 小组代码走查活动时间进度安排如下所示： 2.待评审物 待评审物名称：银行系统取款模块源代码V1.0 （SC-Banking-Withdraw- V1.0） Figure 1 UML Model for Banking-Withdraw
3.成员角色 组长：制定代码走查的计划、安排代码走查活动职责分工、组织代码走查，确保代码走查的过程规范执行； 质量保证人员：制定CheckList，记录代码走查会议以及完成问题记录报告； 开发人员：完成代码，在代码走查中引领走查人员读代码，走查结束后并根据走查的问题记录报告完成代码修改； 评审人员：依据编程规范和CheckList执行代码走查，使用Jupiter工具记录发现的问题。 4.基本原则 4.1 代码评审原则 1.一次检查少于200～400行代码 2.努力达到一个合适的检查速度：每小时少于300～500行代码 3.有足够的时间、以适当的速度、仔细地检查，但不宜超过60～90分钟 4.在复审前，代码作者应该对代码进行注释 5.建立量化的目标并获得相关的指标数据，从而不断改进流程 6.使用检查表（checklist）肯定能改进双方（作者和复审者）的结果 7.验证缺陷是否真正被修复
代码管理制度 1总则 (2) 2源代码完整性保障 (2) 3源代码的授权访问 (2) 4代码版本管理 (3) 5源代码复制和传播 (4) 6系统测试验收流程 (5) 6.1 系统初验 (5) 6.2 试运行 (5) 6.3 系统终验 (5) 6.4 系统验收标准 (6) 6.5 文档评审通过标准 (7) 6.6 确认测试通过标准 (7) 6.7 系统试运行通过标准 (7)
1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。 3源代码的授权访问 1、源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。 第十条在SVN库中设置用户，并为不同用户分配不同的，适合工作的最小访问权限。要求连接SVN库时必须校验SVN中用户身份及其口令。在SVN库中要求区别对待不同用户的可访问权、可读权、可写权。
XXXXXXXX 代码版本管理规范
历史版本
目录 历史版本 (2) 1引言 (4) 1.1目的 (4) 1.2管理工具 (4) 2现状概述 (5) 3现状分析 (5) 3.1现状详述 (5) 3.2目标细化 (6) 3.3SVN版本管理 (6) 3.3.1概述 (6) 3.3.2使用对比 (7) 4完整的实施方案 (9) 4.1开发阶段 (9) 4.2预发布测试阶段 (9)
1引言 1.1目的 为了规范和制度化公司的软件版本管理制度，并保障项目开发资料的完整性和安全性，同时明确开发源代码的控制管理流程，特此制定此规范。 1.2管理工具 沿用SVN管理工具来进行开发的版本管理，源代码管理和开发资料归档。
2现状概述 目前公司研发部门对于代码的版本管理方式较为简单，只是在每次发版后做了基线库存档，导致所有正在开发的需求和项目都在同一个目录里面进行修改，造成每次发版的代码都有可能包含了本次发版以外的内容。 这样会造成如下两点影响： ●会有不稳定的因素存在，比如：测试只会对当前需要发版的内容进行测试，但是代码库 中同时存在多个版本和项目的代码，对于本次发版无涉及的代码没有进过测试就部署到了服务器上，影响运行的稳定性。 ●一旦出现点问题不好定位，比如：出现问题后通常会优先排查发版涉及的内容，但是部 分问题是由于其他项目代码引起的。 因此，随着公司和项目规模的壮大，对软件代码版本管理提出了更高的要求。 3现状分析 3.1现状详述 当前代码版本管理现状如下： 1.所有的开发都在一个目录里面做，各种需求、项目、代码、文件混杂在一起。 2.提交测试服务器时，只考虑了编译能通过，而没有考虑功能本身有没有完成。 3.测试出bug以后，会在开发目录进行修改，然后再次提交到测试服务器。这时提交的 代码就可能包含了他人对其他功能/项目的修改，而测试又只会针对此bug再做测试。 这就导致了除了此bug之外的修改可能会没有测试过就直接发布到了服务器上，引起预发布环境不稳定并增加预发布bug数量。 总体来说，当前工作流程是：预发布出bug，研发修改，再提交测试，然后预发布测试
1源代码管理 (1) 1.1总则 (1) 1.2源代码完整性保障 (1) 1.3源代码的授权访问 (2) 1.4代码版本管理 (2) 1.5源代码复制和传播 (5) 1.6系统测试验收流程 (5) 1.6.1系统初验 (6) 1.6.2试运行 (6) 1.6.3系统终验 (6) 1.6.4应用系统验收标准 (8) 1.6.5文档评审通过标准 (9) 1.6.6确认测试通过标准 (9) 1.6.7系统试运行通过标准 (10)
1代码管理 1.1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 1.2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。
综合征管信息系统 代码走查规范 文档编号： 当前版本： 1.0 修改日期：2010年8月18 日
一、JA V A编程规范 (3) 1、变量定义问题 (3) 2、变量命名规则 (3) 3、变量的声明和初始化(I NITIALIZATION) (3) 4、换行(W RAPPING L INES) (4) 5、M AP对象使用问题 (4) 6、EQUALS方法使用问题 (5) 7、IMPORT多余包问题 (5) 8、N ULL P OINTER E XCEPTION问题 (6) 9、关于对象声明问题 (7) 10、注释 (7) 11、访问静态变量或方法 (8) 12、使用静态变量 (8) 13、I F语句 (8) 14、J A V A源文件的长度 (8) 15、方法的长度 (8) 二、项目开发规范 (8) 1、J A V A文件命名规则 (8) 2、JSP代码规范 (9) 3、CTRL代码规范 (14) 4、E VENT &VO&BO (17) 5、P ROXY代码规范 (18) 6、日志 (20) 7、异常处理 (21) 8、缓存 (22)
一、J A V A编程规范 1、变量定义问题 如果定义的变量只是在某个局部内使用，就在局部内定义，不要在局部外定义。 问题代码： // 返回的明细信息放到vo里传到前台 MAmkdjVO mamkdjVO = new MAmkdjVO(); //如果找到详细信息的记录，就展现 if (responseEvent.getFindNoRecordFlag() == "1") { mamkdjVO = responseEvent.getDetailVO(); 更正代码：(mamkdjVO只是在if条件内使用，只需要自if内定义即可) //如果找到详细信息的记录，就展现 if (responseEvent.getFindNoRecordFlag() == "1") { // 返回的明细信息放到vo里传到前台 MAmkdjVO mamkdjVO = responseEvent.getDetailVO(); 2、变量命名规则 1、禁用差别不大（只有一个或少数几个字母不同）的名称 例如：hiThere和hiThre 2、在名称中禁用下划线字符('_') 3、变量的声明和初始化(Initialization) 1、避免声明的局部变量覆盖上一级声明的变量 2、尽量在声明局部变量的同时初始化。
代码走查指导书 一、目的 1、根据需求、设计尽早发现在各个单元中存在的缺陷，从单元测试阶段抓质量； 2、依靠单元测试，执行代码走查，更快地掌握、了解需求、设计的变更，发现问题并 及时修改测试用例； 3、从另一方面去促使开发人员提高软件编码及单元测试的质量； 4、使测试人员更好地理解业务，掌握项目信息； 二、前提 测试人员需要深刻理解需求、理解设计； 三、测试环境 由测试leader负责搭建一个简易的测试环境，数据库最好与开发部公用； 注：单元测试的很多数据无法通过系统功能去制造，避免因数据的不规范而引发缺陷，所以尽量不要直接在数据库操作； 四、测试范围 1、设计的完整性；（根据提交的单元测试页面及实时变更记录测试） 2、业务的正确性；（根据项目的业务需求测试）（以1为测试前提） 3、功能的正确性；（根据详细设计测试）（以1、2为测试前提） 1）页面所有事件元素（增、删、改、查、上传等按钮、控件的操作）的测试； 2）页面初始状态的默认值测试； 3）设计要求的必输项测试； 4）系统统一设计风格的测试；（如清空查询条件的清空按钮） 5）边界数据的测试； 6）Html源码的测试； 7）接口测试；（以相关接口单元已完成为前提，该测试由测试leader不定期进行，原因：一、多留点时间给测试组员设计、修改测试用例；二、以测试leader的理解 去发现更深层次的问题，也可作为对组员测试工作的检查。） 五、缺陷的记录与修改 1、在测试范围1~6内发现的所有缺陷均记录在SPMS之同级评审--测试走查内； 2、在测试范围7内发现的所有缺陷以邮件的形式发送项目负责人； 六、人员职责划分 测试leader 1、测试版本控制；（开发部提交所有已完成页面的编译包） 2、测试任务的分配（最好是谁写测试用例谁负责测试）、测试时间的控制及测试 结果的发布； 3、查看所有缺陷，过滤一些非缺陷问题，整理共通问题并通知开发人员； 4、接口测试并跟踪修改结果；
基于Tortoise SVN的软件产品版本管理规范[草稿]
目录 1. 引言 (1) 1.1. 目的 (1) 1.2. 范围 (1) 1.3. 术语定义 (1) 1.4. 参考资料 (2) 1.5. 版本控制记录 (2) 1.6. 版本更新记录 (2) 2. 版本管理 (4) 2.1. 版本标示方法 (4) 2.1.1. 正式版本 (4) 2.2. 目录结构 (5) 2.3. 文档的存放 (6) 2.3.1. 开发文档的存放 (6) 2.3.2. 源代码的存放 (6) 2.3.3. SQL的语句存放 (7) 2.3.4. 发行文档的存放 (7) 2.4. 配置管理流程 (7) 2.5. 权限控制的管理 (8) 3. 更新管理 (9) 3.1. 源程序的修改 (9) 3.2. 版本升级 (10) 3.2.1. 版本升级原则 (10) 3.2.2. 新版本发布 (11) 3.3. 文档的变更 (11) 4. 备份管理 (12) 5. 版本工具Tortoise SVN的使用 (13)
1.引言 版本控制就是对软件开发过程中所创建的配置对象不同版本进行管理，保证任何时间都可以取到正确的版本以及版本的组合。 版本控制的主要功能是记录开发过程中的每一次修改，让开发的工作可以随时检查过往历史记录和获得正确版本，是系统的成长记录。 1.1. 目的 本文档的编制是为了规范产品部、研发部、测试部对软件产品版本的管理。 1.2. 范围 本文档为产品部、研发部、测试部的管理员提供有关版本管理规范的相关内容，包括： ●版本标识方法 ●软件系统数据的存放 ●文档的修改控制 ●文档的备份制度 1.3. 术语定义 SCM 软件配置管理（Software Configuration Management）缩写 SVM 软件版本管理（Software Version Management）缩写 SVN 一个开源的版本控制系统Subversion. 文档 一种数据媒体和其上所记录的数据。
源代码管理规范 标准化文件发布号：（9312-EUATWW-MWUB-WUNN-INNUL-DQQTY-
代码管理制度 1总则.................................................................................................. 错误!未定义书签。2源代码完整性保障............................................................................ 错误!未定义书签。3源代码的授权访问............................................................................ 错误!未定义书签。4代码版本管理 ................................................................................... 错误!未定义书签。5源代码复制和传播............................................................................ 错误!未定义书签。6系统测试验收流程............................................................................ 错误!未定义书签。 系统初验........................................................................................... 错误!未定义书签。 试运行............................................................................................... 错误!未定义书签。 系统终验........................................................................................... 错误!未定义书签。 系统验收标准................................................................................... 错误!未定义书签。 文档评审通过标准........................................................................... 错误!未定义书签。 确认测试通过标准........................................................................... 错误!未定义书签。 系统试运行通过标准....................................................................... 错误!未定义书签。
源代码管理文档管理规范 第一章总则 第一条为保障公司源代码和开发文档安全，保证源代码的完整，明确源代码控制管理流程，特制定本源代码管理办法。 第二条本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 第三条源代码直接控制管理部门为产品管理。原代码的内容为我单位万网工程建站的所有相关网站，模板，四川机构网网站代码以及数据库等。 第四条本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 第五条本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 第二章源代码完整性保障 第六条所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 第三章源代码的授权访问 第七条源代码服务器对于共享的TFS库的访问建立操作系统级的，基于身份和口令的访问授权。 第八条在TFS库中设置用户，并为不同用户分配不同的，适合工作的最小访问权限。要求连接TFS库时必须校验TFS中用户身份及其口令。在TFS库中要求区别对待不同用户的可访问权、可读权、可写权。 第九条曾经涉及、触及源代码的计算机在转作它用，或者离开研发部门之前必须由网络管理人员全面清除计算机硬盘中存储的源代码。如果不能确定，必须对计算机中所有硬盘进行全面格式化后方可以转做它用或离开研发部门。 第四章源代码复制和传播 第十条源代码向研发部门以外复制必须获得总经理的书面授权。并必需记录
复制人、批准人、复制时间、复制目的、文件流向、文件版本或内容。 第十一条源代码以任何介质形式进行存储的备份，必须由专人负责保管。对于这些介质地借阅，用于研发部内部使用的必须获得研发部经理的授权，对于用于研发部以外使用的必须获得总经理的书面授权。 第十二条源代码的借阅、复制必须进行详细的登记，必需记录借阅人、批准人、借阅时间、借阅目的、文件流向、文件版本或内容、归还时间。 第十三条任何纸质材料的借阅都必需记录借阅人、批准人、借阅时间、借阅目的、文件流向、文件版本或内容、归还时间。 第十四条对于因合作需要，需要向外复制、传播、分发源代码的，不论是全部还是部分代码和资料，均必需和对方签订技术、源码的保密协定，明确对方应当承担的对源码保密的责任和义务。 第十五条所有已有的开发文档与当前的代码进行统一管理。 第十六条新开发的项目和系统验收时必须与同相关的开发文档同时进行验收。 第五章开发文档管理规范 第十七条所有已有的开发文档与当前的代码进行统一管理 第十八条本规范执行日之后的所有项目的开发必须按开发的基本规则输出开发文档进行备案。 第十九条开发周期在1-3个月以内的项目开发文档保密时效为6个月，开发周期在3个月以上的为一年，保密时效计时为项目结束成功验收之后开始。 第二十条在项目开发中任何以不得未经授权向外发布、流传开发相当的任何文档。
一．目录文件组织 1.所有的文件名符合文件命名规范 2.文件和模块分组清晰 二．程序结构 3.所有的模块（函数和外部接口）定义清晰，模块分解清楚 4.结构设计能够满足机能变更，便于重构 5.模块中所有的数据结构都定义为局部的，并且通过定义好的函数进行访问 6.为外部定义了良好的函数接口，且修改时不影响其他代码模块 7.代码体系构架对空间和速度都已经进行考虑 三．代码组织 8.所有的代码行在80字符以内 9.每个程序文件都小于2000行 10.每个函数显示不超过100行 11.所有的变量声明每行只声明一个 12.所有的变量名都小于32字符 13.所有的函数名都小于64个字符 14.每个函数之间都用空行进行分开 15.所有的行每行最多只有一句代码或一个表达式 四．函数 16.函数注释清楚地描述函数和它的功能 17.函数的名字清晰的定义了它的目标以及函数所做的事情 18.函数的参数遵循一个明显的顺序 19.函数由并列关系的语句组成 20.函数高内聚，只做一件事情，并做好 21.所有的参数小于7个，且都被使用 22.函数使用了最少数目的return语句 23.函数检查了输入数据的合法性 24.函数异常处理清楚 25.函数设计已经考虑了将来的变化
五．数据类型与变量 26.Plugin中尽量避免全局变量的使用 27.每一个变量都在接近使用它的地方才初始化 28.变量的命名完全、明确的描述了该变量代表什么 29.同一种类型命名使用统一的前缀 30.所有的变量都被使用 31.所有的数组访问要考虑越界情况 32.变量在使用前进行必要的null值判断和处理六．条件判断 33.普通的情况在if下处理而不是else 34.最常用的情况最先判断 35.嵌套层次小于3层 七．循环 36.当有明确的多次循环操作，使用For循环 37.当有不明确的多次循环操作，while循环被使用 38.变量定义，数据库读写尽量在循环外进行 39.循环嵌套的次数小于3次 八．注释 40.使用统一的注释模版 41.每个类，每个函数都要有注释 42.注释量不低于20% 43.注释要随着代码改变而进行更新 九．其他 44.无用的代码和注解已经删除 45.页面的布局要符合统一操作说明
第一章总则 第一条为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 第二条本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 第三条源代码直接控制管理部门为研发部。 第四条本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 第五条本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 第二章源代码完整性保障 第六条所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 第七条我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 第八条软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN 库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。 第三章源代码的授权访问 第九条源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。 第十条在SVN库中设置用户，并为不同用户分配不同的，适合工作的最小访问权限。要求连接SVN库时必须校验SVN中用户身份及其口令。在SVN库中要求区别对待不同用户的可访问权、可读权、可写权。 第十一条曾经涉及、触及源代码的计算机在转作它用，或者离开研发部门之前必须由网络管理人员全面清除计算机硬盘中存储的源代码。如果不能确定，必须对计算机中所有硬盘进行全面格式化后方可以转做它用或离开研发部门。 第四章源代码复制和传播 第十二条源代码向研发部门以外复制必须获得总经理的书面授权。并必需记录复制人、批准人、复制时间、复制目的、文件流向、文件版本或内容。 第十三条源代码以任何介质形式进行存储的备份，必须由专人负责保管。对于这些介质地借阅，用于研发部内部使用的必须获得研发部经理的授权，对于用于研发部以外使用的必须获得总经理的书面授权。 第十四条源代码的借阅、复制必须进行详细的登记，必需记录借阅人、批准人、借阅时间、
软件版本管理规范 1.第一章目的 本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容，使软件项目版本管理流程化并规范化，确保在系统开发和实施过程中项目的完整性和一致性。 2.第二章适用范围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。 3.第三章职责 配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。 此岗位可由开发或测试人员兼任。 4.第四章内容 4.1. 版本管理对象 包括但不限于： ?项目总体计划 ?可行性研究报告 ?开发计划 ?需求说明书 ?需求设计原型 ?设计说明书 ?系统开发变更申请单 ?系统管理手册 ?用户操作手册 ?培训计划 ?培训记录 ?源程序 ?支持系统运行的配置文件
?存储过程脚本 ?测试计划 ?测试用例 ?测试脚本 ?测试报告 ?上线计划 ?上线申请 ?版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目内部的目录结构建议按下列格式创建。 配置库目录结构规划： ┠tags(发布) ┃ ├v1.0.0_T1_2016909 ┃ ├v1.0.0.33899_T1_20161009 ┃ ├v1.0.0_R1_20161109 ┃ ├v1.1.0_T1_20170109 ┃ └v1.1.0_R1_20170209 ┠trunk(主版本) ┃ └projectA ┃ ├src ┃ ├MY_MOOC ┃ ├doc ┃ ├tool ┃ ├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC
版本管理规范 一、版本管理办法 1.1目的 按照一定的规则保存项目源程序的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确的查找到项目各个板块的任何版本。为保障公司源代码和开发文档安全不被泄漏，保证选代码的完整性，明确源代码控制管理流程，特制定此管理办法。 1.2适用部门 本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 1.3管理部门 源代码直接控制管理部门为软件部。 1.4控制范围 本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 1.5角色与职责 所有项目成员都必须遵照版本控制规则操作各个项目板块。 1.6版本管理工具Virsual SVN 用此工具对项目开始阶段的开发，和项目中期的变更进行版本的管理。避免发生版本丢失或混淆等现象，详细使用方法见：《Virsual SVN操作细则》 1.7项目各板块版本变迁规则 各板块的状态有3种：“草稿”（Dralt）、“正式发布”（Released）和“正在修改”（Changing） 各板块状态变迁如图所示： 各板块刚建立时其状态为“草稿”。各板块通过评审（试用）后，其状态变为“正式发布”。此后若更改各板块源代码，必须填写“版本变更情况表”及“版本变更状态跟踪表”，且版本状态变为“正在修改”，修改后通过审批（试用）其状态又为“正式发布”。以此循环。 二、SVN管理规范 2.1帐号密码的配发规则 根据岗位需要，针对不同人员，设置不同权限。遇岗位变更，随时增加删除权限。用户名：为姓名的‘姓’的全拼音+‘名’的开头拼音。 密码：一人一密码。 2.2上传文件注意事项 1.修改后的文件及文件夹的名字，跟修改前的必须同名，否则识别不了，当成新增
源代码、技术文档管理制度初稿 一、总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 4、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 5、曾经涉及、触及源代码的计算机在转作它用，或者离开研发部门之前必须由行政部管理人员全面清除计算机硬盘中存储的源代码。如果不能确定，必须对计算机中所有硬盘进行全面格式化后方可以转做它用或离开研发部门。 二、源代码、技术文档的授权访问 2.1源代码、技术文档保存办法 源代码、技术文档采用FTP方式上传到公司指定服务器，并设置用户，并为不同用户分配不同的，适合工作的最小访问权限。要求连接服务器时必须校验FTP中用户身份及其口令。在服务器中要求区别对待不同用户的可访问权、可读权、可写权。 服务器采用台式电脑搭建于总经理办公室内。 2.2用户划分如下： 表2.1 FTP用户划分 三、源代码、技术文档上传管理流程 3.1源代码、技术文档上传管理流程图
图3.1源代码、技术文档上传管理流程图 3.2采用定期上传备份 为了保证文档的最大可恢复性，要定期地进行上传备份工作。如果处于开发阶段，每周
应对所有的源程序项进行备份，一般为每周周五；如果处于其它阶段，根据具体情况而定，但周期不能超过两周。 3.3 录入登记表 四、源代码、技术文档下载管理流程 4.1源代码、技术文档下载管理流程图
XXXX公司 技术文件 软件版本管理规范 XXXX公司 二○一八年一月
目录 第1章引言 .................................................... - 1 - 1.1 目的 ................................................... - 1 - 1.2 适用范围 ............................................... - 1 - 1.3 术语定义和缩写词 ....................................... - 1 - 1.4 统一大小写 ............................................. - 1 - 1.5 参考资料 ............................................... - 1 -第2章版本规范 ................................................ - 2 - 2.1 版本格式 ............................................... - 2 - 2.2 版本升级规则 ........................................... - 2 -第3章 TAG 规范 ................................................ - 3 - 3.1 TAG 转换规则 ........................................... - 3 - 3.2 版本 TAG ............................................... - 3 - 3.2.1 ALPHA测试 TAG .................................... - 3 - 3.2.2 BETA测试 TAG ..................................... - 3 - 3.2.3 Release TAG ...................................... - 3 - 3.2.4 产品基线 TAG ..................................... - 4 -第4章 BRANCH 规范 ............................................. - 5 - 4.1 固定后缀 ............................................... - 5 - 4.2 BRANCH 转换规则 ........................................ - 5 - 4.3 项目 BRANCH ........................................ - 5 -