Git规范
分支管理
分支命名
master 分支
- master 为主分支，也是用于部署生产环境的分支，确保master分支稳定性
- master 分支一般由develop以及hotfix分支合并，任何时间都不能直接修改代码
develop 分支
- develop 为开发分支，始终保持最新完成以及bug修复后的代码
- 一般开发的新功能时，feature分支都是基于develop分支下创建的
feature 分支
- 开发新功能时，以develop为基础创建feature分支
- 分支命名: feature/ 开头的为特性分支， 命名规则: feature/user_module、 feature/cart_module
release分支
- release 为预上线分支，发布提测阶段，会release分支代码为基准提测
当有一组feature开发完成，首先会合并到develop分支，进入提测时，会创建release分支。
如果测试过程中若存在bug需要修复，则直接由开发者在release分支修复并提交。
当测试完成之后，合并release分支到master和develop分支，此时master为最新代码，用作上线。
hotfix 分支
- 分支命名: hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似
- 线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支，修复完成后，需要合并到master分支和develop分支
常见任务
增加新功能
(dev)$: git checkout -b feature/xxx
# 从develop建立特性分支 (feature/xxx)$: blabla
# 开发 (feature/xxx)
$: git add xxx (feature/xxx)
$: git commit -m 'commit comment' (dev)
$: git merge feature/xxx --no-ff # 把特性分支合并到develop
修复紧急bug
(master)$: git checkout -b hotfix/xxx # 从master建立hotfix分支 (hotfix/xxx)
$: blabla # 开发 (hotfix/xxx)$: git add xxx (hotfix/xxx)
$: git commit -m 'commit comment' (master)
$: git merge hotfix/xxx --no-ff # 把hotfix分支合并到master，并上线到生产环境 (develop)
$: git merge hotfix/xxx --no-ff # 把hotfix分支合并到develop，同步代码
测试环境代码
(release)$: git merge develop --no-ff # 把develop分支合并到release，然后在测试环境拉取并测试
生产环境上线
(master)$: git merge testing --no-ff # 把testing测试好的代码合并到master，运维人员操作 (master)$: git tag -a v0.1 -m '部署包版本名' #给版本命名，打Tag
二、Git提交信息规范
当前业界应用的比较广泛的是 Angular Git Commit Guidelines
1 介绍
Git进行commit时都需要提交说明（commit message）：
Git commit -m 'hello world'
-m参数就是用来指定commit message的
commit message应该清晰明了，说明本次提交的目的。
2 Commit message的格式
Commit message应该包括三个部分：Header/Body/Footer。其中，Header是必需的，Body和Footer可以省略。
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
不管是哪一个部分，任何一行都不得超过72个字符（或100个字符）。这是为了避免自动换行影响美观
2.1 Header
只有一行，包含三个字段，type（必须）、scope（可选）和subject（必须）
（1）type
用于说明commit的类别，只允许使用一下8个标识：
- feature：添加新功能
-
fix：修补bug -
docs：仅仅修改了文档 -
style：仅仅修改了空格、格式缩进、逗号等等，不改变代码逻辑 -
refactor：重构（即不是新增功能，也不是修改bug的代码变动） -
test：增加测试用例 - performance: 增加代码进行性能测试
-
chore：改变构建流程、或者增加依赖库、辅助工具等
（2）scope
用于说明commit影响的范围，比如数据层、控制层、视图层等，是项目不同而不同
（3）subject
是commit的简短描述，不超过50字符
例如fix: array parsing issue when multiple spaces were contained in string.
- 义动词开头，使用第一人称现在时（change，而不是changed）
- 第一个字母小写
- 结尾不加句号(.)
2.2 Body
是对本次commit的详细描述，可以分成多行：
More detailed explanatory text, if necessary. Wrap it to
about 72 characters or so.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Use a hanging indent
有两个注意点：
1. 使用第一人称现在时
2. 说明代码变动的动机，以及与以前行为的对比
2.3 Footer
只是用与两种情况
（1） 不兼容变动
如果当前代码与上一个版本不兼容，则Footer部分以BREAKING CHANGE开头，后面是变动的描述以及变动理由和迁移方法
BREAKING CHANGE: isolate scope bindings definition has changed.
To migrate the code follow the example below:
Before:
scope: {
myAttr: 'attribute' ,
}
After:
scope: {
myAttr: '@',
}
The removed `inject` wasn't generaly useful for directives so there should be no code using it.
（2）关闭Issue
如果当前commit针对某个issue，那么可以在Footer部分关闭这个issue
Closes #123, #245, #992
2.4 Revert
有一种特殊情况，如果当前commit用于撤销以前的commit，则必须以revert:开头，后面跟着被撤销的Commit的Header
revert: feature(pencil): add 'graphiteWidth' option
This reverts commit 667ecc1654a317a13331b17617d973392f415f02.
Body部分的格式是固定的，必须写成·This reverts commit ·
Commitizen
一个撰写合格的Commit message的工具
安装：
npm install -g commitizen
然后，在项目目录里，运行下面的命令，使其支持 Angular 的 Commit message 格式。
commitizen init cz-conventional-changelog --save --save-exact
以后凡是用到 git commit 的命令，一律改为 git cz ，这时，就会出现选项，用来生成符合格式的Commit message。
validate-commit-msg
用于检查Node项目的Commit message是否符合格式，需要手动安装
首先拷贝这个JS文件到代码库，命名为validate-commit-msg.js
然后把这个脚本加入Git的Hook，在package.json中使用ghooks，把这个脚本加为commit-msg时运行
"config" : {
"ghooks" : {
"commit-msg" : "./validate-commit-msg.js"
}
}
然后每次Git commit时脚本就会自动检查Commit message是否合格，不合格就会报错
简单的示例
feature: 新增分析师清理功能
分析师清理功能，包括
1 . 查询分析师
2 . 分时段清理
不包含正文的提交说明
docs: correct spelling of CHANGELOG
包含作用域的提交说明
feature(lang): added polish language
为fix编写的提交说明，包含可选的issue编号
fix: minor typos in code
see the issue for details on the typos fixed
fixes issue #12
为什么使用约定式提交Commit message
- 自动化生成 CHANGELOG。
- 基于提交的类型，自动决定语义化的版本变更。
- 向同事、公众与其他利益关系人传达变化的性质。
- 触发构建和部署流程。
- 让人们更容易地探索结构化的提交历史，降低贡献项目的难度。
