[TOC]
git workflow 规范
概要说明
分支管理和开发流程
基本分支： master、develop、release/xxx、hotfix/xxx、feature/dev_xxx
master/release 分支，用来上线，打tag
从 master 分支拉一个 develop 分支，用来开发演进，合并代码，最终会 merge 到 master 上
-
从 develop 拉一个 feature/dev_xxx 分支，相关开发需求都提交到 dev_xxx 上，开发完了之后，merge 到 develop 部署测试环境
- dev_xxx 分支合并到 develop 上之后删除 dev_xxx 分支
- dev_xxx 分支一般都是临时功能开发用，合并后就没有保留的必要了
develop 分支开发完了以后，基于 develop 分支开一个
release/$version的分支，部署测试环境验证ok后，将release/$version合并到 master验证一下，然后打 tag 上线
其他说明：
- master 分支是最稳定的，在 develop 分支开发稳定后，开一个 release 分支后 merge 到 master 上打tag
- dev_xxx 是功能开发分支，单人协作的时候，一般 merge 就可以。 如果是多人协作，那么一般自己本地的分支上开发提交，但是不 push 到远程，但是每次提交都 rebase 一下远程的 dev_xxx 分支。两个好处：
- git log 的线会好看很多，少很多，看起来更方便
- 冲突的概率会少很多，rebase 的时候，也不至于把自己的 commit 穿插到别人中，这样自己之前的 commit 在 rebase 后就是一个新的 commit 时间线
基准规范
基本分支规范
- 首先基于 master 分支创建 develop 分支
- 然后在 develop 分支基础上开一个 feature/xxx 的分支用来做开发
- 开发完新特性后 merge 到 develop；并且同时删除 feature/xxx
- develop 开发完了之后，基于 develop 创建一个
release/$version支；用来 部署到 dev、pre 环境做测试-
release/$version的 version 就是版本号名
-
- 测试 ok 之后，merge 到 master ，然后打 tag 上线
hotfix 规范
- 基于之前release/xxx 检出新的 hotfix/xxx 分支，然后修复验证后合并到 er 和 develop 分支
- 然后基于 master 再打 tag 上线
代码提交
- 提交的信息，全部采用英文
- 通过 commitizen 工具来提交（git cz 代替 git commit）
- 通过 standard-version 做版本发布和自动生成 Changelog
代码 code review
feature/xxx 需要合并到 develop 的时候，通过 gitlab 创建一个 merge request ，然后指定其他同时或者上级领导，进行代码合并
-
feature/xxx，要求尽可能少的代码提交，当一个小的功能完备后就需要 MR。
- 如果有大的功能特性，需要分步提交，方便 review
