一、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分支。