git flow 工作流程

写在前面：在网上能够看到很多的关于git flow 工作流程的博客或者文章，我将我的工作中的git flow的管理方式和大家分享一下，本文话粗理不粗值得多看，git flow 你的team值的拥有！！！

图片来源于互联网

首先，git 上应该有一下几个分支模型：

• master: master 分支为主分支【不能直接push代码】，也是新功能拉取的分支，分支有着每次功能上线的tag;在初始化git仓库的时候就会创建；
• hosfix: 热修补分支
• release：线上代码对应分支【不能直接push代码】
• qa:测试分支，可以设置git 钩子自动部署代码，提高效率
• feature: 开发人员新功能开发分支

git flow工作流程：

• devloper：新功能开发分支一般命名为（feature_name或feature/name）；开发人员在进行功能开发的时候，先从master 分支checkout新的feature分支（例如feature/open_activity）,分支拉取后，开发人员在当前分支开发自己的功能，开发完成后，merge feature/open_activity到 qa分支进行功能测试，经过QA测试该功能没有问题，merge feature/open_activity 到 release 分支（release 分支不能直接push代码，需要request merge,code review之后，就可以在灰度环境测试，然后上线了），到此为止新的功能已经上线完成，delete feature/open_activity分支、 merge release 分支到master 分支，并且打下tag。整个一个开发流程结束，新的需求一个轮回又开始了；

• bugfix:bugfix分支一般命名为（bugfix_name或bugfix/name）； bugfix 是对重大bug的修改，修改完成后，需要合并到qa分支进行测试，整个流程与 #devloper# 的流程一致；

• hotfix: hotfix分支一般命名为（hotfix_name或hotfix/name）； hotfix为线上代码的热更新，比如配置文件的修改或者极小的功能修改。开发人员从master 拉取hotfix/mysql_config分支，然后进行bug fix ,完成后，merger 到release分支code review之后上线。到此bug热修复完成，delete hotfix/mysql_config分支、merge release 分支到master 分支，hotfix一般不需要打tag；

git flow 是一种开发流程，也是github建议的一种开发方式，同样很多git可视化客户端工具对git flow提供了更方便的操作；

写在后面，本文我引用的这张图能够很好的表达清楚整个工作流程，请详细理解，我会在评论中把上图的整个开发流程以及具体的操作进行详细的说明！