前言
这篇文章主要介绍Github Flow的理念，以下内容来源于《Github入门与实践》。
Github Flow是以部署为中心的开发模式，通过简单的规则，持续高速且安全地进行部署。而Gitflow则是以发布为中心的分支管理模型，它提供了一种更灵活的方式来管理代码库中的更改。可以参考《Gitflow工作流简单介绍（以发布为中心的开发模式）》
基本概念
整体的开发流程如下，令master分支时常保持可以部署的状态；进行新的作业时要从master分支创建新分支，新分支名称要具有描述性；在新建的本地仓库分支中进行提交；在GitHub端仓库创建同名分支，定期push；需要帮助或反馈时创建Pull Request，以 Pull Request进行交流；让其他开发者进行审查，确认作业完成后与master分支合并；与master分支合并后立刻部署。
由于流程中基本只需为特定作业创建特定分支，从开始作业到进行部署之间的过程十分简单，可以降低开发者学习开发流程的成本。
特点
- 随时部署，没有发布的概念
这个流程必须遵守"令master分支随时保持可以部署的状态"，也就意味着每隔几小时就可能进行一次部署，所以不存在发布的概念（"发布"是指创建软件版本的过程，使得可以管理和追踪不同版本的软件，并提供用户下载和使用。"部署"是指将软件版本从开发环境转移到生产环境的过程，让软件可以运行在目标平台上，并向用户提供服务）。
不过要注意，没有进行过测试或者测试未通过的代码绝不可以合并到master分支。因此势必要用到持续集成等手段。 - 进行新的作业时要从master分支创建新分支
- 在新创建的分支上进行细粒度的提交
有意识地减小提交规模，一方面便于清楚地表达目的，另一方面有助于其它开发者对Pull Request进行审查。