参考：
一.分支简述
- 蓝圆--主线(master)
- 紫圆--主分支(dev)（生产主线）
- 橙圆--新功能开发主线(feature)
- 绿圆--新版本发布线(release)
- 红圆--发布版本bug修复线(hotfix)
二.工作流程
工作流基础
项目负责人创建dev分支供团队开发人员围绕它进行相关操作
git branch dev
git push -u origin dev
其他人clone，创建一个dev的轨迹版本
git clone git@github.orgXXXXXXXX
git checkout -b dev origin/dev
dev这个分支将包含项目的完整历史记录，而master仅包含缩略版本。
新功能开发流程
1.新建feature分支
在dev基础上创建新分支：
git checkout -b feature/demo dev
推到远程，(然后这部分新功能代码就提交到这个上)
git push
所有开发此新功能的人员，都在这个分支上开发提交代码
git status
git add
git commit -m "Add some-file."
2.完成新功能开发（合并feature分支到dev上去）
git pull origin dev
git checkout dev
git merge feature/demo
git push
git branch -d feature/demo
注意
- 新功能分支，永远不要直接在master上合并，要在dev上进行操作
- 合并时做好冲突合并（webstrom可实现自动合并）
3.测试环境发布dev分支代码（提交测试）
线上版本发布流程
（1）从dev中创建发布的release分支
当主测试流程完成，源码已经趋于稳定，准备一个发布版本（确立版本号）,并推到远程
git checkout -b release-1.0 dev
git push
这个分支是清理准备发布、 整体回归测试、 更新文档，和做其他任何系统即将发布的事情。
（2）开发交代码改bug
（3）release分支合并到master和dev
一旦已经满足发布条件（或已经到了预定发布日期），应该把release分支合并到master分支和dev分支中，然后，使用master发布新版本。合并release分支到dev分支是很重要的，要让release上修改的东西能在后续的开发分支中生效。
master
git checkout master
git merge release-1.0
git push
dev
git checkout develop
git merge release-1.0
git push
git branch -d release-1.0
（4）打标签
Release分支在功能开发分支（dev）和公共发布版（master）中，充当一个缓冲的作用。每当有源码合并到master中的时候，应该在master上打一个标签，以便后续跟踪查阅。
git tag -a 1.0.RELEASE -m "Initial public release" master
git push --tags
线上bug修复过程
当用户反馈系统有bug，需从master基础上创建并维护hotfix新分支，解决完在合并回master
（1）创建hotfix
git checkout -b issue-#001 master
（2）修复
（3）完成后合并到master发布
git checkout master
git merge issue-#001
git push
（4）打标签
（5）合并到dev
git checkout develop
git merge issue-#001
git push
三.小结
- master仅包含缩略版本，dev包含项目完整历史记录
- 添加新功能都在dev上新生成分支feature进行操作，然后在合并回dev上
- 版本：在dev上测试流程完成，源码趋于稳定时，在dev上创建一个release作为发布版本号（其实就是master和dev之间的一个缓冲）
- 线上修bug：反馈出bug之后，在master基础上新建一个分支hotfix，在该hotfix上修好了在合并回master，并同步到dev
