Gitlab 分支管理规范

Gitlab Flow

项目的分支状态为：

• master：主分支，用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；
• develop：开发分支，用于日常开发，存放最新的开发版；
• feat-xxx <feature branch>：功能分支，一旦完成开发，它们就会被合并进develop或master，然后被删除；
• hotfix-xxx<hotfix branch>：正式环境补丁分支，一旦完成开发，它们就会被合并进develop或master，然后被删除；
• fix-xxx<fix branch>：开发环境补丁分支，一旦完成开发，它们就会被合并进develop或master，然后被删除；

分支详解

master 主分支

代码库有且仅有一个主分支。提供给用户使用的正式版本，都在这个主分支上发布。每次发布打上Tag标签，如：0.1，0.2 或 0.3。

develop 开发分支

开发人员日常开发与功能测试分支。如果想正式对外发布，需在Master分支上，对Develop分支进行 "合并"（merge）操作。由于Gitlab中默认对Master设置了分支保护(这个设置允许取消,如果存在多人开发的项目,不建议取消)，所以，当需要合并到Master的时候需要在Gitlab里提交合并申请由项目管理员合并。

feat-xxx

• 功能分支属于临时性分支，一般合并完就会删除。它是为了开发某种特定功能，从master分支上面分出来。开发完成后，再并入Develop分支。
• 功能分支的名字，可以采用feat-xxx的形式命名。

bug分支

• 项目测试与正式发布之后，难免会出现bug。这时就需要创建一个分支，进行bug修复。

• bug出现环境不一样，可定义不同的bug分支。

  • 测试环境：从develop上新建分支为fix-xxx；
  • 正式环境：从master上新建分支为hotfix-xxx；

Gitlab分支权限管理

权限类型

GitLib有五种身份权限，分别是：

• Owner 项目所有者，拥有所有的操作权限
• Master 项目的管理者，除更改、删除项目元信息外其它操作均可
• Developer 项目的开发人员，做一些开发工作，对受保护内容无权限
• Reporter 项目的报告者，只有项目的读权限，可以创建代码片断
• Guest 项目的游客，只能提交问题和评论内容

分支管理规范

命名规范

分支名称	分支命名	功能介绍
主分支	master	正式环境发布
开发分支	develop	测试与开发环境发布
功能分支	feat-xxx	使用禅道的需求编号(如果对应的需求编号过多,也可以使用拼音缩写)
修复分支	hotfix-xxx	使用禅道的bug工单号，或者根据当前tag版本号增加
修复分支	fix-xxx	使用禅道的bug工单号

提交内容规范

Git 每次提交代码，都要写 Commit message（提交说明），否则就不允许提交。但是，一般来说，commit message 应该清晰明了，说明本次提交的目的。提交规范设置为：" type:subject "

type

用于说明 commit 的类别，只允许使用下面7个标识。

• feat：新功能（feature）
• fix：修补bug
• style： 格式（不影响代码运行的变动）
• refactor：重构（即不是新增功能，也不是修改bug的代码变动）
• test：增加测试

subject

subject 是 commit 类型的简短描述，不超过50个字符。

其他注意事项：结尾不加句号（.）

优点

• 可读性好，清晰，不必深入看代码即可了解当前commit的作用。
• 为 Code Reviewing做准备
• 方便跟踪工程历史
• 让其他的开发者在运行 git blame 的时候想跪谢
• 提高项目的整体质量，提高个人工程素质

提交分支规范

• 禁止向主分支直接提交代码，包扩代码仓库在线编辑修改。特殊情况（如版本号变更、CI变更）除外；
• 禁止提交测试性代码到任何主分支源码（src）目录，测试代码只能存在于测试（test）目录；
• 禁止任何工作分支跨主分支提交代码，工作分支从只能合并到与工作分支同源的主分支；
• 禁止在开发过程修改主分支版本号；
• 必须在代码提交到主分支前删除未使用的import语句和格式化代码。
• 必须备注每一次提交，代码备注必须简要可读。准确的描述具备可检索性；
• 必须备注每一次合并请求，对合并请求包含的功能点简要描述。准确的描述具备可检索性。

开发流程管理

迭代开发流程规范

1. 总体组每周四制定下一迭代版本上线计划并确定迭代开发主分支版本号通知到各中心（组）；
2. 各中心（组）责任人认领确认任务（截止周五），分解任务并下发开发人员，开发在新版本分支上开发；
3. 各中心（组）在周四前完成基本任务提交到迭代版本主分支交由测试组集成验证；
4. 测试组在集成测试分支打包测试，bug提交到禅道管理，相关责任人及时认领并修复，同时通知测试组回归测试；
5. 上线值日人需在每周四下班前确定最终项目版本并归档输出；
6. 各中心（组）责任人提交最终《数据库变更脚本》、《环境变更脚本》通知到上线值日人；
7. 各中心（组）责任人提交《程序变更说明》、《上线验证功能列表》到测试组；
8. 上线值日人需要负责生产环境war包发布和数据库变更；
9. 测试组依据《上线验证功能列表》验证生产系统发布正确性；
10. 测试组验证无误依据《程序变更说明》发布上线变更通知。测试不通过通知上线值日人回滚本次发布程序和数据库及环境变更；
11. 总体组确定延期发布计划；
12. 延期上线流程参照本章第五条至第十条执行；
13. 其他时间未经批准禁止发布程序和变更数据库操作

线上Bug修复流程

1. 以线上版本master主分支为源创建hotfix-xxx的修复分支；
2. 在hotfix-xxx的修复分支进行集成环境bug修复并向线上版本主分支提交合并请求；
3. 中心（组）责任人负责代码审核，同意或者拒绝本次合并请求；
4. 测试组根据最新代码在集成测试环境进行补丁修复验证；
5. 验证无误后将本次合并请求同时cherry-pick到集成迭代开发主分支；
6. 发布流程参照【迭代开发流程规范的第五条至第十条执行】；

测试Bug修复流程

1. 以集成测试主分支为源创建fix-xxx的修复分支；
2. 在fix-xxx的修复分支进行集成环境Bug修复并向集成测试主分支提交合并请求；
3. 中心（组）责任人负责代码审核，同意或者拒绝本次合并请求；
4. 测试组根据最新代码在集成测试环境进行补丁修复验证；
5. 验证无误后将本次合并请求cherry-pick到迭代开发主分支；
6. 发布流程参照【迭代开发流程规范的第五条至第十条执行】；