一、Git分支管理
我们在实际工作中会创建很多分支以便于不同场景下的开发，但是如果没有分支规范就会造成分支杂乱，大家往往也搞不清楚某一个分支是在做什么，下面我们就介绍一下我们常用的并且推荐大家使用的分支类型。
Master: 主分支
- 主要是稳定的版本分支，正式发布的版本都从Master拉。
Develop: 开发分支
- 更新和变动最频繁的分支，正常情况下开发都是在Develop分支上进行的。
Release：预发行分支
- 一般来说，代表一个版本的功能全部开发完成后递交测试，测试出Bug后进行修复的分支。
Features: 功能分支
- 里面包含了每个程序员开发的功能点。Feature开发完成后合入Develop分支。
HotFix: 修复分支
- 这个分支的存在是在已经正式上线的版本中，发现了重大Bug进行修复的分支。
二、Git日志规范
在一个团队协作的项目中，开发人员需要经常提交一些代码去修复bug或者实现新的feature。而项目中的文件和实现什么功能、解决什么问题都会渐渐淡忘，最后需要浪费时间去阅读代码。但是好的日志规范commit messages编写有帮助到我们，它也反映了一个开发人员是否是良好的协作者。
目前，社区有多种 Commit message 的写法规范。来自Angular 规范是目前使用最广的写法，比较合理和系统化。建议使用如下：
# fix：修复支付宝支付bug
#
# 1，修复支付完成后未查询支付状态问题
# 2，增加定时任务保证支付状态完整
#
# link：http://github.com/ftd/shopmall/issue001
三、Git Flow工作流
我们现在已经了解了Git的分支，包括分支有哪些类型，什么情况下使用什么类型的分支，以及提交的格式规范等。不过往往在一个团队人数较多，创建的分支也比较多的时候，还是会带来很多分支操作上的困扰。那有没有一个什么好的流程来规范大家呢，针对这些问题，建议大家使用Git Flow的工作流模式。
「1，主分支流程」
- master分支记录了每次版本发布历史和tag标记。
- develop分支记录了所有开发的版本历史。
- develop分支仅第一次创建时从master分支拉取。
「2，开发流程」
- feature分支是从develop分支拉取的分支。
- 每个feature完成后需合并到develop分支。
「3，提测发布流程」
- release分支是在所有功能开发自测完成后，从develop分支拉取的分支。
- release分支一旦创建后，就不再从develop分支拉取，该分支只做bug修复，文档生成和其他面向发布的任务。
- release分支测试完成，达到上线标准后，需合并回master分支和develop分支。
「4，bug修复流程」
- hotfix分支是在线上出现bug之后，从master分支拉取的分支。
- hotfix分支测试完成后，需合并回master分支和develop分支。
