一、git 分支管理策略

（1）主分支 master

一般情况下，项目所提供给用户使用的正式版本，都应该在这个主分支上发布。

（2）开发用分支 dev

功能的集成分支，改分支用于日常开发，迭代功能开发测试通过之后，如果要正式对外发布，就将 dev 分支合并到 master 分支。

（3）临时分支

新的临时分支从 master 拉取, 保证代码最新。使用完毕后，需要及时删除。

临时分支包括以下两种：

（3-1）功能分支

作用为开发某个特定功能，从 dev 分支上分出来，开发完成后需要再合入 dev 分支。

命名规范：feature-{功能名称}-{姓名缩写}，如 feature-deleteRole-LiSi

（3-2）bug 修复分支

作用为修复某个线上 bug，从 master 分支上分出来，修复结束后再合入 dev 和 master 分支。

命名规范：hotfix-{功能名称}-{姓名缩写}，如 hotfix-AddUser-ZhangSan

注：bug 修复分支需要先 merge origin master 以获取最新修改。且该类型的分支只能被合并，不能主动合并除了 master 分支之外的分支，以避免误带上别的分支

二、分支提交规则

（1）开发人员本地分支所做的功能修改，必须完成自测；

（2）如果可以，开发人员尽量对本地代码review通过后再进行代码合并；

【附】review规则：

（a）每一个小的版本迭代完后，就去Review代码；

三、本地分支管理

（1）本地分支每次修改之前，首先要进行 pull 操作；

（2）本地要做到勤提交，比较大的功能模块要进行细化拆分，分次提交，避免同时提交大量代码所引发的代码冲突；

（3）本地分支在进行 merge 操作时，必须将远程先 merge 到本地，本地自测完成后，再提交到远程仓库；

四、git提交规范

（4-1）commit操作要遵循的规范：

（4-1-1）每次commit 尽量只针对于一件事；

（4-1-2）书写commit message时要言简意赅；

（4-1-3）规范commit message格式；

（4-2）commit 组成

提交信息包括三个部分：Header，Body 和 Footer。

其中，Header 是必需的，Body 和 Footer 可以省略。

（4-2-1）Header格式：:

type：用于说明 commit 的类别，如：feat、fix等

（4-2-1-1）type 对应的类型说明：

feature：新增功能；

fix：修复bug；

docs：修改文档；

refactor：代码重构，未新增任何功能和修复任何bug；

build：改变构建流程，新增依赖库、工具等（例如webpack修改）；

chore：非src和test的修改；

test：测试用例的修改；

ci：自动化流程配置修改；

revert：回滚到上一个版本；

feat：完成一些功能

style：样式修改

perf：一些优化重构

chore：引入一些第三方库等

subject：本次commit的简短描述，以及物动词开始，15个字内

（4-2-2）Body

Body 是对本次 commit 的详细描述，可以分成多行。

注意：应该说明代码变动的动机，以及与以前行为的对比。无重大变更，一般不写。

（4-2-3）Footer（一般不写）

Footer 一般只用于以下几种情况

关联 Issue（Issue #1, #2, #3）

关闭 Issue（Close #1, #2, #3）

可用github关闭issue，或者与自己的任务相关联

【***** 提交示例：git commit -m “feature：新增用户注册” 】

【 提交示例：git commit -m “fix: 修复角色添加失败问题” *****】

五、标签使用规范

（1）主分支每个阶段性的发布操作，都应该按需进行分支版本切换（如 rerelease-v1.0）或者通过标签来进行版本标记；

（2）本地每完成一个大的里程碑，打一个标签，标签名称要含义清晰，

（2-1）标签命名规则：

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

（a）架构升级或架构重大调整，修改第2位

（b）架新功能上线或者模块大的调整，修改第2位

（c）架bug修复上线，修改第3位

六、提交频率

1、每天下班前已完成的部分必须提交到 dev 分支，并push到远程仓库；

2、临时分支要尽量按照功能点或修复重构的问题及时commit；

私信666领取资料