1.分支管理
1.1 总览
从上图可以看到主要包含下面几个分支：
master: 主分支，主要用来版本发布。
develop：日常开发分支，该分支正常保存了开发的最新代码。
feature：从develop分支fork，合并回develop。具体的功能开发分支。
release：从develop分支fork，合并回develop和master。一般用于发布正式版本之前（即合并到 master 分支之前），需要有的预发布的版本进行测试。
hotfix：从master分支fork，合并回develop和master。线上 bug 修复分支。
1.2 主分支(master, develop)
主分支包括 master 分支和 develop 分支。master 分支用来发布，HEAD 就是当前线上的运行代码。develop 分支就是我们的日常开发。使用这两个分支就具有了最简单的开发模式：develop 分支用来开发功能，开发完成并且测试没有问题则将 develop 分支的代码合并到 master 分支并发布。
1.3 辅助分支(feature , release, hotfix)
feature 分支用来开发具体的功能，一般 fork 自 develop 分支，最终可能会合并到 develop 分支。一般feature分支都存在于开发者本地，开发期间使用git rebase来保证和develop分支的代码同步并解决冲突。功能开发完毕后push到远程仓库，然后提交pull request，合并到develop分支。
release 分支在我看来是 pre-master。release 分支从 develop 分支 fork 出来，最终会合并到 develop 分支和 master 分支。合并到 master 分支上就是可以发布的代码了。有人可能会问那为什么合并回 develop 分支呢？很简单，有了 release 分支，那么相关的代码修复就只会在 release 分支上改动了，最后必然要合并到 develop 分支。比如，当开发一个较长期的feature不着急上线但又需要部署测试时，可以从develop分出一个release分支，feature提交pull request到这个release分支，然后部署这个release分支到测试服。
hotfix 分支用来修复线上 bug。当线上代码出现 bug 时，我们基于 master 分支开一个 hotfix 分支，修复 bug 之后再将 hotfix 分支合并到 master 分支并进行发布，同时 develop 分支作为最新最全的代码分支，hotfix 分支也需要合并到 develop 分支上去。
1.4 分支命名
除了主要分支的名字是固定的之外，派生分支是需要自己命名的，这里就要有个命名规范了。强烈推荐用如下形式：
master 主分支，发布分支
dev 主分支，开发分支
feat_xxx——按照功能点（而不是需求）命名；
release_xxx——用发布时间命名，可以加上适当的前缀；
hotfix_xxx——GitLab 的 issue 编号或 bug 性质等。
小写字母下划线形式
1.5 版本号命名
格式为：x.y.z，其中，x 用于有重大重构时才会升级，y 用于有新的特性发布时才会升级，z 用于修改了某个 bug 后才会升级。
v1.1.1：第一位大版本号，大功能发布时增加，技术负责人审核；第二位小版本号，增加小特性时增加，主开发审核；第三位BUG修复号，修复BUG用，修复人员负责。
每次发布生产(master)，需要为master打一个tag，方便线上回滚
2.开发规范
2.1 Commit原则
只要坚持做到以下几点就 OK 了：
提交时的粒度是一个小功能点或者一个 bug fix，这样进行恢复等的操作时能够将「误伤」减到最低；
用一句简练的话写在第一行，然后空一行稍微详细阐述该提交所增加或修改的地方；
不要每提交一次就推送一次，多积攒几个提交后一次性推送，这样可以避免在进行一次提交后发现代码中还有小错误。
2.2 Commit Message 格式
<type>(<scope>): <subject> （不超过50个字）
<空行>
<body> （每行不超过72个字）
<空行>
<footer>
type
feat：新功能（feature）
fix：修补bug
mod：修改（即不是新增功能，也不是修改bug的代码变动）
refactor：重构
docs：文档（documentation）
style： 格式（不影响代码运行的变动）
test：增加测试
chore：构建过程或辅助工具的变动
Scope
用来说明本次Commit影响的范围，即简要说明修改会涉及的部分。这个本来是选填项，但从AngularJS实际项目中可以看出基本上也成了必填项了。
Subject
用来简要描述本次改动，概述就好了，因为后面还会在Body里给出具体信息。并且最好遵循下面三条:
以动词开头，使用第一人称现在时，比如change，而不是changed或changes
首字母不要大写
结尾不用句号(.)
Body
里的内容是对上面subject里内容的展开，在此做更加详尽的描述，内容里应该包含修改动机和修改前后的对比。
Footer
footer里的主要放置不兼容变更和Issue关闭的信息
Revert
此外如果需要撤销之前的Commit，那么本次Commit Message中必须以revert：开头，后面紧跟前面描述的Header部分，格式不变。并且，Body部分的格式也是固定的，必须要记录撤销前Commit的SHA值。
示例
feat: 增加港股经纪商队列
增加港股经纪商队列接口和后台名称编辑接口
增加同时获取买卖盘和经纪商的接口
BREAKING CHANGE: 删除了旧版十档买卖盘接口