团队多人协作，必须要有一个适合团队的，规范的工作流程
协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去。"工作流程"在英语里，叫做"workflow"或者"flow"，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。
市面上主要有3中工作流Git flow，Github flow，Gitlab flow。这里我们采用Git flow工作流。
下面具体介绍该工作流
主要特点
首先，项目存在两个长期分支。
- 主分支master
- 开发分支develop
前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；后者用于日常开发，存放最新的开发版。
（两个长期分支）
其次，项目存在三种短期分支。
- 功能分支（feature branch）
- 补丁分支（hotfix branch）
- 预发分支（release branch）（可用个人开发分支替代）
日常开发
创建个人开发分支，基于远程 dev 创建
git checkout -b feature-a origin/dev同步 dev 分支
git rebase origin/dev- 完成开发，commit，push 远程。
- 发起合入 dev 分支请求（使用 gitlab 新建合并请求）
- 管理者接受合并请求，代码合并进入 dev 分支。
预发布版本测试、正式发版
- 创建预发布分支（如：release-1.0.0），基于 dev 分支创建预发布分支
- 测试预发布分支代码
- 测试通过后，合入 master 分支
- 正式发布版本，打版本 tag
bug 修复
预发布版本 bug 修复
创建bug分支，基于预发布版本分支创建。（假设预发布版本分支为：release-1.0.0）
git checkout -b 15-release-1.0.0-bug-a origin/release-1.0.0建议 bug 分支命名规范：与 issue 的名字保持一致，并且以issue的编号起首。如"15-release-1.0.0-bug-a "。
开发完成后，在提交说明里面，可以写上"fixes #14"或者"closes #67"。Gitlab 规定，只要commit message里面有下面这些动词 + 编号，就会关闭对应的issue。
如未创建 issue，去掉头部的编号。- 完成修复 bug ，本地提交（commit），push 远程。
- 发起合入预发布版本分支（使用 gitlab 新建合并请求）。
发起合入 dev 分支（使用 gitlab 新建合并请求）。
注意：bug 修复完成后，同时需要合入 dev 分支
- 管理者接受合并请求，代码合入目标分支。
master（线上） bug 修复
流程同 "预发布版本 bug 修复" 流程
区别在于
- 创建分支是基于 master 分支创建
- 分支名为 15-master-1.0.0-bug-a
- bug 修复完成后，发起合入 master 分支和 dev 分支。
