Git使用规范
2019-03-14 本文已影响0人
程序员与工匠
[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位