正确使用git flow及commit message 规范指南

Git Flow

就像代码需要代码规范一样，代码管理同样需要一个清晰的流程及规范。

• 如何开始一个新特性的开发，而不影响阻塞其他特性开发？
• 分支多了如何管理，时间久了，如何知道每个分支是干什么的？
• 哪些分支已经合并回了主干？
• 如何进行Release的管理？开始一个Release的时候和另外正在开发的Feature冲突如何解决, 预发布如何才能不阻塞新的功能的开发？
• 线上代码出Bug了，如何进行修复管理？

Git Flow是Vincent Driessen在2010年提出的一个Git 管理模型，如图。

GitFlow包括如图五种分支

• master
• develop
• feature
• release
• hotfix

以上图已经算把Git Flow的核心思想囊括在内了，看懂了上图，也就明白了Git Flow。

下面我们一一进行详解。

主要分支

master

master分支在该模型指一个生产环境分支，或者说是一个交付分支，不允许直接在分支上进行修改提交，只允许merge，且每次merge都应该当打上tag记录版本号。

develop

develop为主开发分支，包含最新的预发布的功能代码。该分支主要合并自其他分支，如Feature。

支撑性分支

其他三种都是支撑性、功能性、临时性的分支。

feature

创建自：develop，必须合并回：develop，命名:feature/xxxxx。，合并方式，注意–no–ff

feature用于开发一些后期会做版本发布的新功能，一旦开发完成，我们应当合并回Develop分支，并且删除该feature分支。

或者直接不合并直接删除（开发出来结果不理想或者需求变更）。

feature 在标准 Git Flow模型中只作为一个local本地分支，不需要推送至origin远端分支，当然如果为了多人协作考虑，不需要严格遵守。

release

创建自：develop，必须合并回：master、develop，命名:release/xxxxx。

当我们一个或多个feature分支开发完成并合并回develop分支时，你认为可以进行版本发布了，这个时候我们就可以根据develop分支创建release进行release流程，分支名为release，但是实际上他叫pre release更为合适。

这个分支上一般是没啥东西的提交，更多的是要求我们做版本发布前的基础自测，并可以在该分支上对自测发现的问题进行bug fix，不允许进行在该分支进行新特性开发，自测没问题了就可以并入devlop和master分支，在该分支做的bug修复可持续性集成回develop分支，不需要跟master一样确认无误才合并，同样–no–ff，对master分支打tag。

hotfix

创建自：master，必须合并回：master、develop，命名:hotfix/xxxxx。

hotfix和release比较类似，都是为了新交付版本发布做准备，不过release属于计划内正常的发布，而hotfix这更多是在生产环境出现严重bug需要尽快紧急修复,同时develop分支尚不稳定，无法支撑一次release发布，也没有正在进行的release分支，这是我们可以从master拉取一个hotfix分支就此bug进行修复。

同理在hotfix只允许进行bug以及打版本号之类的操作。修复完合并回master、develop。

小结

Git Flow通过使用创建分支，以获得并行互不冲突的开发环境，并且通过规范化的管理方式，管控这些临时分支命名、合并方式、生命周期等。

总的来说，Git Flow 并不是什么复杂的东西，只是让大家形成一个共同的思维模型，以达到形成一个更易于管理、易于理解的git仓库的目的。

规范化提交

Git 每次提交代码，都要写 Commit message（提交说明），否则就不允许提交。

目前市场上，有多种Commit message 的写法规范，我们目前推行的angular规范，该规范目前是使用比较广泛的写法之一。

commit message格式

每次提交，提交都应当包含三部分，标题，主体、脚注

():    // header   必须
// 空一行
                       //body     可选
// 空一行
                     //footer   可选

Commit Message Header

单行，包含三个字段type（必须），scope（可选），subject（必须）

<type>(<scope>): <short summary>
  │       │             │
  │       │             └─⫸  commit 目的的简短描述，不超过50个字符，以动词开头
  │       │
  │       └─⫸ Commit Scope: 说明 commit 影响的范围，比如网络层、前处理层、推理层等等，视项目定义不同自行划分。
  │  
  │
  └─⫸ Commit Type: feat|fix|docs|style|perf|refactor|test|build|ci|

type划分：

feat：引入新功能(feature)
fix：修补bug
docs：添加或更新文档(documentation)
style： 格式调整（不影响代码运行的变动，空格，花括号换行）
perf: 性能提升的代码更改(performance)
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试代码用例
build：依赖调整，影响构建系统、或者外部依赖第三方库的更改
ci：持续集成CI、CD的配置文件或者脚本的更改
chore：不属于之上范畴的其他不修改源文件及测试文件的其他杂项更改

Commit Message Body（可选）

相比head，更为清晰详细的说明，比如解释为什么做提交，以及改动影响了什么，代码思路等等等等，可以多行，注意一行不要超过70字

Commit Message Footer（可选）

脚注主要用来关联issues，对于gitlab之类的平台可以用commit关联并自动关闭issues。

还可以写一些 BREAKING CHANGE，描述一些与之前冲突不兼容的改动。

BREAKING CHANGE: 大概描述
// 空一行
<详细描述以及迁移指南>
// 空一行
// 空一行
Fixes #<issue number>  //github、gitlab等平台，在commit合并到master会自动关闭对应issue

好处

• 结构清晰，方便浏览，
• 更好的根据msg提供过滤选项快速查找信息，例如git log --pretty=oneline --grep feat: 过滤出全部feat类commit
• 可以根据commit信息生成changelog