Git使用规范

[TOC]

工作流指南

分支分类

• 历史分支
  master: 存储了正式发布的历史,为主分支(保护分支)，不能直接在master上进行修改代码和提交;
  develop:作为功能的集成分支,开发完成需要提交测试的功能合并到该分支;
• 功能分支
  feature: 大家根据不同需求创建独立的功能分支，开发完成后合并到develop分支；
• 发布分支
  release: 发布分支，主要用于测试或修复bug。
• 维护分支
  hotfix: 为bug修复分支，需要根据实际情况对已发布的版本进行漏洞修复，必须从master拉取；

流程图解

image.png

命名规范

分支命名

功能分支： featrue/功能名称
发布分支：release/版本号-功能名称-发布日期
维护分支：hotfix/版本号-问题概述或issueid-日期 (最好使用issue建立问题描述?)
例如： release/转投优化-20181111

常见问题

分支管理策略

1. develop为集成开发分支

 提交规则： 
 自己分支自测完毕；
 review通过再合并；

2. 本地分支管理

本地分支必须从**线上版本节点**checkout();
本地分支要做到勤提交，分小功能提交；
一个功能点一个分支(自己控制)，至少保证保留两个分支：  新版本分支、优化分支；
本地分支merge到develop分支时，必须先merge develop到本地分支，自测通过再提交；

3. 注意事项

开发者相同版本尽量不要修改相同功能，提前划分或协商清楚；
如果修改代码涉及多人功能，提交完毕请及时告知相关人员；
开发者每天更新develop分支内容到本地分支，避免大规模merge; 
fixbug分支修改测试完，立即合并到develop上！ 

提交规范

Commit

Commit message一般包括三部分：Header、Body和Footer。
Header
type(scope):subject

• type：用于说明commit的类别，规定为如下几种
  feature：新增功能；
  fix：修复bug；
  docs：修改文档；
  refactor：代码重构，未新增任何功能和修复任何bug；
  build：改变构建流程，新增依赖库、工具等（例如webpack修改）；
  style：仅仅修改了空格、缩进等，不改变代码逻辑；
  perf：改善性能和体现的修改；
  chore：非src和test的修改；
  test：测试用例的修改；
  ci：自动化流程配置修改；
  revert：回滚到上一个版本；
• scope：【可选】用于说明commit的影响范围
• subject：commit的简要说明，尽量简短

Body
对本次commit的详细描述，可分多行

Footer
不兼容变动：需要描述相关信息
关闭指定Issue：输入Issue信息

Merge

代码合并、master分支操作，请在gitlab 提交 merge request,负责人进行代码review后，才能同意合并操作。

Tag(Version)

采用三段式，v版本.里程碑.序号，如v1.2.1

• 架构升级或架构重大调整，修改第2位
• 新功能上线或者模块大的调整，修改第2位
• bug修复上线，修改第3位

参考文档：http://www.crom.cn/topics/338