Git Flow的工作流程

公司

目的

目前的开发流程

优点

适合个人开发，方便快捷，没有分支创建、切换成本

缺点

1. 多人开发，易在开发中产生冲突，阻碍开发
2. 临时线上bug需要修复时，必须将上一个release tag检出，修复后发布bugfix release tag，然后手动合并到master
3. 无脚本自动化，易产生发布故障

Git Flow开发流程

优点

1. 多人开发，互不干扰
2. 区分master、hotfix、release、develop、feature分支，脚本化操作，不容易出错

介绍

master分支

包含产品代码、不能在master分支上开发

develop分支

进行新的开发的基础分支，等待被整合到master分支

feature分支

用于新功能的开发，从develop分支检出

git flow feature start rss-feed
git flow feature finish rss-feed

release分支

如果develop分支已经完成所有的开发和自测，以发布的版本号生成release分支，从develop检出。提交视觉走查、产品验收和集成测试，提交相关的bug。

git flow release start 1.1.5
git flow release finish 1.1.5

完成release后，会将代码合并到master和develop分支，标记tag，删除版本分支，并且回到develop分支。合并到master时，触发部署。

hotfix分支

发布后出现bug，创建hotfix分支，从master分支上检出。

git flow hotfix start missing-link
git flow hotfix finish missing-link

完成hotfix后，改动合并到master和develop分支上，进行标记，删除分支，回到develop分支

bugfix分支

在开发过程中出现bug，创建bugfix分支，从develop检出。个人认为是feature的特例，只是为了方便识别。具体查看讨论。

实践

个人开发者

使用master、develop、release、hotfix分支即可，日常开发迭代在develop上，功能验收和视觉走查在release上，线上bug修复在hotfix上。

多人开发

日常开发在feature上，功能验收和视觉走查在release上，线上bug修复在hotfix上。

参考

• git-flow 的工作流程
• Using git-flow to automate your git branching workflow
• How to use a scalable Git branching model called Gitflow
• gitflow-avh