git分支规范

git 分支类型

master：主分支，用于版本持续发布；
develop：开发分支，即日常迭代使用的开发分支，用于日常开发持续集成；
feature：特性分支，用于日常开发时切出分支进行单功能开发；
bugfix：故障修补分支，通常用于修复故障；
release：发布分支，适用于产品发布、产品迭代；
hotfix：热修分支，用于产品发布后修复缺陷；
custom：自定义分支，用户可以自定义需要的分支类型。

分支命名规则

单项目情况下
分支类型-功能标签-人员（如：feature-ops-yyh）
多项目情况下
${项目名称}-分支类型-功能标签-人员（如：sc-feature-ops-yyh）

提交规则

在领到日常开发任务时，基于 master 或（项目-dev）创建 feature 特性开发分支，提交代码后，合并至 master 并删除 feature。
在领到修复故障的任务时，基于 master 或（项目-dev）创建 bugfix 故障修补分支，提交代码后，合并至 master 并删除 bugfix。
需要发布时，同样需要基于 master 创建 release，生成的应用版本部署在 UAT 测试环境进行测试，若需要修改则提交至 release。（待定）
产品上线后发现故障需要紧急进行热修复时，则基于 tag 创建 hotfix，将修复的代码提交至 hotfix；部署该分支上的版本通过验收后，基于 hotfix 打出热修版本的 tag，如 0.8.1。（待定）
由于新版本的迭代也同时进行，所以需要在 hotfix 上 rebase master，变基至 master 分支最新的提交，再合并至 master 并删除 hotfix，就可以将本次修改的提交应用至 master 上。（待定）

提交格式要求

格式示例

代码回滚比较特殊，如果本次提交是为了恢复到之前的某个提交，那提交消息应该以“revert:”开头，后跟要恢复到的那个提交的标题。然后在消息正文中，应该写上“This reverts commit ”，其中“”是要还原的那个提交的 SHA 值。
修改类型 type（type 代表某次提交的类型，比如是修复一个 bug 还是增加一个新的 feature）

feat:新增 feature
fix:修复 bug
docs:仅仅修改了文档，比如 README, CHANGELOG,CONTRIBUTE 等等
style:仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑
refactor:代码重构，没有加新功能或者修复 bug
perf:优化相关，比如提升性能、体验
test:测试用例，包括单元测试、集成测试等
chore:改变构建流程、或者增加依赖库、工具等
revert:回滚到上一个版本
build: 构建工具或构建过程等的变动，如：gulp 换成了 webpack，webpack 升级等
影响范围 （暂时不需要）

范围不是固定值，它可以是你提交代码实际影响到的任何内容。例如 location、browser、compile、rootScope、ngHref、ngClick、ngView 等，唯一需要注意的是它必须足够简短。
当修改影响多个范围时，也可以使用“*”。

标题

标题是对变更的简明描述：
使用祈使句，现在时态：是“change”不是“changed”也不是“changes”
不要大写首字母
结尾不要使用句号

正文

正文是对标题的补充，但它不是必须的。和标题一样，它也要求使用祈使句且现在时态，正文应该包含更详细的信息，如代码修改的动机，与修改前的代码对比等。

页脚

任何**Breaking Changes（破坏性变更，不向下兼容）**都应该在页脚中进行说明，它经常也用来引用本次提交解决的 GitHub Issue。

Breaking Changes应该以“BREAKING CHANGE:”开头，然后紧跟一个空格或两个换行符，其他要求与前面一致。

关闭 Issue

如果当前 commit 针对某个 i ssue，那么可以在 Footer 部分关闭这个 issue 。
Closes #234
也可以一次关闭多个 issue 。
Closes #123, #245, #992