[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位
