git flow 普片认为最早是由荷兰独立软件工程师Vincent Driessen在2010年发表的一个成功的Git分支模型(A successful Git branching model)这篇文章提出的。文章中提到文森特早在一些项目中使用git flow，并证明它是成功的。文中提及使用git flow的根据分支策略解决自动构建和部署问题。文森特后来制作了nvie/gitflow工具用于扩展git实现git flow功能，gitflow思想也推广了出去。
仓库在一般的情况下存在master和develop两个主要分支。
master主分支，存放稳定的、随时能上线的版本。develop开发分支，所有开发的基础分支。
根据项目的需要可能添加下面这些分支：
hotfix修复分支，会从master分支开一个hotfix分支进行修复，修复完成后分别合并至master和develop。feature功能分支 ，当需要开发新功能时从develop分支创建，完成后合并至develop分支。release预发布分支，当develop需要提测时合并至release分支，测试完成后release合并至masster和develop。
每个分支都有其职责，为团队中的开发人员缓解功能跟踪、预构建及快速修复等问题。在一些场景下gitflow会显得很臃肿，在一些快速迭代的产品中会使你必须在master, develop, release三条分支中频频切换来完成合并维护，写将会花费你大量的时间和精力。
对于giflow的过于繁琐和复杂，Scott Chacon提出gitflow的问题和github-flow的思想。
什么是github-flow呢？
- 首先master分支中的任何内容都是可部署的
- 创建一个来自master的具有描述性的分支（如：new-oauth2-scopes）
- 在本地提交该分支，并定期将您的工作推送到服务器上的同名分支
- 当您需要反馈或帮助时，或者您认为分支已准备好进行合并时，请打开拉取请求（PR）
- 在其他人审阅并签署该功能后，您可以将其合并到master中
- 一旦合并并推送到“master”，您就可以并且应该立即部署
在github有完整的指引
新分支只专注单个功能进行开发，使开发者更专注于编码而已不是管理这些状态。github-flow中增加了合并请求(PR)和检查代码(review)部分更是为项目提供了很好的保护，在这步能很好的控制编码风格和编码错误等问题，检查和审核他人的代码不但让组内成员相互学习提高项目参与感。同时也为团队降低了人员流失所带来的风险。合并前的部署环节为分支代码提前在生产环境测试，这将会是上线前的最终测试，通过测试后将合并至主分支发布上线。
能看出github-flow比gitflow少了预发布、修复、增加功能、开发的分支，工作流程简单了许多。但是预发布、修复、增加功能、开发等概念在整个软件开发过程中任然是存在的，其他环节无需在编码环节上体现出来。github-flow只专注编码，其作为在软件开发的编码阶段是具有非常高的参考价值。