git开发规范
1.分支
1.1主要分支
master： 永远和线上产品最后一次发布的代码一致，保证代码的稳定和可靠性， 分支一般由develop以及hotfix分支合并，任何时间都不能直接修改代码
develop： 始终保持最新完成以及bug修复后的代码 ，最新的开发完整功能的分支，（完整功能是指某个模块、需求或者特性完全开发完成后才合并到develop上）这master和dev两个分支，所有开发人员都没有push权限，只有开发组长或者其他专人有merge权限，开发人员在自己的分支开发完成后，提交merge请求，开发组长或者其他专人负责review后进行合并，一般开发新功能时， feature分支是基于develop创建的。
1.2其他分支
**feature分支：**开发新功能时，基于develop创建的 feature 分支
分支命名规范 feature/ 开头的为特性分支，命名规则: feature/user_module
release分支： release为预上线分支，发布提测阶段，会release分支代码为基准提测
当有一组feature开发完成，首先会合并到develop分支，进入提测时，会创建release分支。
如果测试过程中若存在bug需要修复，则直接由开发者在release分支修复并提交。
当测试完成之后，合并release分支到master和develop分支，此时master为最新代码，用作上线。
复制代码
**hotfix分支：**分支命名以hotfix/开头的为修复分支，他的命名规则与feature类似，线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支，修复完成后，需要合并到master分支和develop分支
1.3常见场景
增加新功能
(dev)$: git checkout -b feature/xxx # 从dev建立特性分支
(feature/xxx)$: blabla # 开发
(feature/xxx)$: git add xxx
(feature/xxx)$: git commit -m 'commit comment'
(dev)$: git merge feature/xxx --no-ff # 把特性分支合并到dev，负责人进行review
修复紧急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，并上线到生产环境
(dev)$: git merge hotfix/xxx --no-ff # 把hotfix分支合并到dev，同步代码
测试环境代码
(release)$: git merge dev --no-ff # 把dev分支合并到release，然后在测试环境拉取并测试
生产环境上线
(master)$: git merge testing --no-ff # 把testing测试好的代码合并到master
(dev)$: git merge testing --no-ff # 把测试好的代码合并到dev分支，同步代码
(master)$: git tag -a v0.1 -m '部署包版本名' #给版本命名，打Tag
2.提交日志规范
为什么需要提交日志规范： 在一个团队协作的项目中，开发人员需要经常提交一些代码去修复bug或者实现新的feature。而项目中的文件和实现什么功能、解决什么问题都会渐渐淡忘，最后需要浪费时间去阅读代码。但是好的日志规范commit messages编写有帮助到我们，它也反映了一个开发人员是否是良好的协作者。
编写良好的Commit messages可以达到3个重要的目的：
- 加快
review的流程 - 帮助我们编写良好的版本发布日志
- 让之后的维护者了解代码里出现特定变化和feature被添加的原因
目前来自Angular 规范是目前使用最广的写法
每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
// 步骤一: 输入第一行
git commit -m "1. 第一行
// 步骤二: 按Enter 输入第二行
git commit -m "1. 第一行
2. 第二行
// 步骤三: 输入完毕，补齐引号，提交！
git commit -m "1. 第一行
2. 第二行"
其中，Header 是必需的，Body 和 Footer 可以省略。
不管是哪一个部分，任何一行都不得超过72个字符（或100个字符）。这是为了避免自动换行影响美观。
2.1 Header
Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。
2.1.1 type
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，建议是不要。
2.1.2 scope
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
2.1.3 subject
subject是 commit 目的的简短描述，不超过50个字符。
2.2 body
Body 部分是对本次 commit 的详细描述，可以分成多行。
2.3 Footer
- 不兼容变动
如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法。
- 关闭 Issue
如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue 。 (这里不是很懂)
