一、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领取资料
