背景
部门引入了新的发布系统，对代码和分支的提交加强了管理。
规范
git commit log
目前社区主流的是 Angular 规范。
具体规则：
-
每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。
-
其中，Header 是必需的，Body 和 Footer 可以省略。
-
Header部分只有一行，包括三个字段：
type（必需）、scope（可选）和subject（必需）。
-
type用于说明 commit 的类别，只允许使用下面7个标识。- feat：新功能（feature）
- fix：修补bug
- docs：文档（documentation）
- style： 格式（不影响代码运行的变动）
- refactor：重构（即不是新增功能，也不是修改bug的代码变动）
- test：增加测试
- chore：构建过程或辅助工具的变动
如果
type为feat和fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore、style、refactor、test）由你决定，要不要放入 Change log. -
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。 -
subject是 commit 目的的简短描述，不超过50个字符。- 以动词开头，使用第一人称现在时，比如
change，而不是changed或changes - 第一个字母小写
- 结尾不加句号（
.）
- 以动词开头，使用第一人称现在时，比如
工具链：
-
Commitizen 撰写合格 Commit message
-
conventional-changelog-cli 生成 Change log
git 分支策略
Git常见的三种协作开发模式：Git Flow & GitHub Flow & Gitlab Flow。我们采用的是 Git Flow 的方式。
分支说明：
-
master分支（生产分支）
长期分支，经过充分测试的稳定发布版本，对应线上生产运行环境，只接受来自release分支和hotfix分支的合并。
-
develep分支（开发分支）
长期分支，经过开发自测过的新功能集成可用版本，对应开发集成环境，只接受来自feature分支、bug分支、hotfix分支的合并。
-
release分支（预发布分支）
临时分支，一个项目里程碑的测试预发布版本，对应测试环境，测试通过可用合并到master分支（升级生产），不接受直接提交代码，只接受来自bug分支的合并，演进路径：develop → release → master。
-
feature分支（需求分支）
临时分支，开发者本地正在开发的新需求分支，对应需求开发负责人的本地环境，该分支有两个来源：直接提交代码和来自task分支的合并请求，演进路径： develop → feature → develop。
-
task分支（任务分支）
临时分支，开发者本地正在开发的新任务分支，对应任务开发者本地环境，该分支可以直接提交代码，演进路径：feature → task → feature。
-
bug分支（测试缺陷分支）
临时分支，开发者本地正在修复的测试缺陷分支，对应开发者本地环境，该分支可以直接提交代码，演进路径：release → bug → develop&release 或者 develop → bug → develop。
-
hotfix分支（生产缺陷分支）
临时分支，开发者本地正在修复的生产缺陷分支，对应开发者本地环境，该分支可以直接提交代码，演进路径：master → hotfix → master&develop&release。
