代码管理及出包规范 V1.0.doc

代码管理及出包规范代码管理及出包规范版本信息 A代表新增，M代表修改，D代表删除。版本号发布日期提交人A.M.D摘要V1.02016-05-19林彦A拟初稿1. 前言41.1. 目的41.2. 配置管理工具41.2.1. Git介绍41.2.2. Git分层结构41.2.3. 工作流程61.3. 角色和职责62. 配置仓库规范72.1. 配置仓库说明72.2. 配置仓库管理规范72.2.1. 远程仓库管理82.2.2. 本地仓库管理83. 分支管理规范93.1. 分支职责93.2. 分支工作流程图103.3. 创建分支规范114. 代码管理规范114.1. 提交代码规范114.1.1. 代码提交说明114.1.2. 代码提交步骤114.1.3. 解决冲突124.2. 代码开发测试规范125. 版本管理规范125.1. 版本格式125.2. 命名规则135.3. 出包说明135.4. 出包步骤131. 前言 1.1. 目的l 规范项目代码管理流程，明确开发人员和项目管理者的职责。 l 规范代码库分支管理和版本管理，使代码分支及版本结构清晰，方便维护。1.2. 配置管理工具 1.2.1. Git介绍 Git是一个开源的分布式版本控制系统，用以有效、高速的处理从很小到非常大的项目版本管理。可以实现数据备份、记录历史、回到过去、多端共享、分工合作。1.2.2. Git分层结构git的工作总共分四层，其中三层是在本地，包括了工作目录，暂存区和本地仓库。工作目录：执行命令git init时所在的地方，也是执行一切文件操作的地方。暂存区：在.git文件夹目录中，在工作区和版本库中间起缓存作用的一个区域。它通过git add命令添加进暂存区。存储了一些即将被commit的文件。本地仓库：在.git文件夹目录中，使用了git commit命令之后添加进的真正的“仓库”。里面存储了每次commit的记录，每次commit一次会让HEAD指针指向新的目录树，而旧的目录就存在版本库中，可以使用命令来提出之前的目录树。git所存储的都是一系列的文件快照，然后git来跟踪这些文件快照，发现哪个文件快照有变化它就会提示你需要添加到暂存区或是提交到本地仓库来保证你的工作目录是干净的。进入工作区.git文件夹，如下.git目录或文件结构说明：目录或文件说明config文件项目的配置文件，里面有中心服务器的信息和分支信息。HEAD文件指向当前的分支。index文件暂存区的相关信息。logs目录相关操作产生的日志。objects目录存储的就是所有的数据，也就是快照。存放的是实际上的文件资源，每次当使用了git add命令之后，就已经把文件存到了objects目录里面。objects目录中的object对象都有一个通过哈希算法计算出来的40位16进制的id，前两位是目录名，后38位是文件名。因为哈希算法可以只比较哈希值，就能知道这两个对象是不是一样的，这样可以提高效率。 refs目录存储指向数据提交对象的指针。1.2.3. 工作流程1.3. 角色和职责角色名称职责 配置管理员管理配置服务器，维护代码仓库、安全设置，定期备份代码仓库。负责为项目提供全面的配置管理基础设施和环境。包括代码仓库建立、人员添加等工作。编写和维护配置管理的相关文档，包括服务器配置管理方法、配置工具使用方法、配置规则与实行方法等。编写培训材料，制定培训计划，对开发人员和项目管理人员进行培训。 开发负责人1) 管理源代码，构建代码框架，导入配置服务器。2) 在配置管理员协助下对源代码进行管理。3) 根据项目进展制定开发基线，管理版本编号以及分支版本，必要的时候，负责版本的合并，并解决或指导开发人员解决合并冲突。4) 负责发布新版本。 开发人员1) 从服务器克隆项目，按照分配的任务，进行分工协同开发。2) 从服务器获取代码库最新变更，在自己负责的模块中加入、修改或删除文件。3) 及时提交代码到开发分支并附加变更说明。配置管理员各角色工作流程图创建仓库 远程仓库开发负责人合并分支 开发人员 开发人员 开发人员提交代码克隆仓库2. 配置仓库规范2.1. 配置仓库说明 配置管理员负责建立配置仓库，以便管理源代码、相关文件及资料。每个开发人员在本地都有自己的版本库，在服务器上有一个公共的版本库。2.2. 配置仓库管理规范根据配置管理的不同角色所分配的不同职责范围，对本地库和版本库进行管理和操作。2.2.1. 远程仓库管理l 配置管理员:创建远程仓库、人员添加等工作。l 开发负责人:导入该项目到远程仓库并完成分支的创建和设置。2.2.2. 本地仓库管理本地库由开发人员和开发负责人负责日常的更新和开发工作。1. 克隆远程仓库，搭建开发环境开发人员根据配置管理提供的git访问地址，将远程仓库克隆到本地，使工作区可以正常运行起来，并在开发分支上创建功能分支进行开发工作。2. 代码提交开发人员修改完成后提交代码到暂存区，在暂存区域生成文件快照并提交到本地和远程开发分支，由开发负责人来进行代码的审核和合并。建议开发人员及时同步代码，以避免冲突和丢失修改。同时，开发人员必须保证上传的代码是通过编译的。对于涉及更改项目结构的操作，应由开发负责人负责执行。3. 对项目进行分支和标记标签在开发过程中，很多时候需要对一个项目进行分支操作，在开发分支上对项目进行开发。这由开发人员负责执行。当项目开发到一个特定阶段，由开发负责人为项目打上标记标签，作为一个项目开发的里程碑或开发基线。至此就完成了对一个新项目的开发管理过程。3. 分支管理规范3.1. 分支职责1、 主分支master代码库应该有一个、且仅有一个主分支。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。2、 开发分支develop用于日常开发，存放最新的开发版的一个主要分支。不管是要做新的feature还是需要做bug fix，都是从这个分支分出来做。在这个分支下主要负责记录开发状态下相对稳定的版本，即完成了某个feature或者修复了某个bug后的开发稳定版本。3、 辅助分支feature: 开发新功能的分支, 基于 develop, 完成后 merge 回 develop。release: 准备要发布版本的分支, 用来修复 bug. 基于 develop, 完成后 merge 回 develop 和 master；hotfix: 修复 master 上的问题, 等不及 release 版本就必须马上上线. 基于 master, 完成后 merge 回 master 和 develop。3.2. 分支工作流程图 图 3-1 工作流程图3.3. 创建分支规范1.配置管理员在建立仓库时创建一个master分支和develop分支。2.开发人员根据开发的功能点从develop分支创建一个feature分支，当功能点开发测试完毕之后，就会合并到develop分支去，可以将feature分支删除。3.当需要发布一个版本来测试时，开发人员从develop分支创建一个release分支来测试，它的命名，可以采用release-*的形式。4.正式发布后，过程中出现bug,从master分支创建一个hotfix分支，修补结束以后，再合并进Master和Develop分支。4. 代码管理规范4.1. 提交代码规范4.1.1. 代码提交说明由对应分支修复的实际开发人员提交到开发分支，开发负责人需要进行判断是否需要合并，并解决冲突代码。提交的信息包括代码的修改、提交者信息、提交时间以及提交的注释描述。4.1.2. 代码提交步骤1. 同步远程仓库代码，和远程仓库进行代码合并。2. 将分支工作区修改的代码和提交描述等提交到开发分支。3. 开发负责人对提交的分支代码进行审核和合并，并解决冲突。4. 同步到主分支上。4.1.3. 解决冲突pull同步工作区，找到冲突文件，解决冲突重新提交。4.2. 代码开发测试规范1新功能开发的代码，内部白盒测试覆盖率要达到100%，特别是针对多条件判断的代码，例如ifelse、switch、while、for等情况，不能只对其中的初始输入条件想当然，要遍历所有可能输入，对于异常情况的输入也要纳入初始条件中。2. 定期使用Find Bugs插件检查自身写的模块代码质量，可以减少低级错误。 5. 版本管理规范 5.1. 版本格式V主版本号. 子版本号. 阶段版本号. 日期版本号. 阶段版本号如：v1.0.0.20160606.realease主版本号：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。子版本号：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。阶段版本号：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。日期版本号:用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。阶段版本号:此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。5.2. 命名规则l 每次提交必须写明注释，如果是修复Bug，请加上Bug号l 创建特性分支，名称要以f-开头，加上特性名l 创建发布分支，名称要以r-开头，加上预发布版本号l 创建Bug修复分支，名称要以b-开头，加上Bug号l 创建标签，名称要以t-开头，加上发布版本号 5.3. 出包说明 从主分支上导出需要发布的版本，导出的发布版本包必须是可靠的。在测试环境回归完成后的包，需要同步更新到项目组的测试环境，保证测试环境的代码是最新的。5.4. 出包步骤