GitHub flow，顾名思义，就是 GitHub 所推崇的 Workflow。千万不要理解成 GitHub 上才能用的 Workflow。
其官网的描述为：
GitHub flow is a lightweight, branch-based workflow that supports teams and projects where deployments are made regularly.
从中我们可以得出的信息是 —— 这段描述完全就是废话 GitHub flow 具有很高的通用性。
为了更便于了解 GitHub flow 的内容，我们从流程图入手：
其中的主要流程为：
- 新建分支（Create a branch）；
- 提交修改（Add commits）；
- 创建 PR（Open a Pull Request）；
- 代码评审（Discuss and review your code）；
- 部署（Deploy）；
- 合并（Merge）；
细心的同学可能很快会发现，GitHub flow 最大的亮点在于部署（Deploy）发生在 合并（Merge）之前，这就是 GitHub flow 的核心，非阻塞式集成 —— 在产生任何副作用之前得知当前修改的所有集成效果，达到真正的持续集成。
GitHub flow 有什么优势？
GitHub flow 的核心优势在于其流程带来的自动化可能性，能够做到其它流程无法实现的检查过程，并极大简化开发团队的体力劳动，真正发挥自身的价值。
如何开始使用 GitHub flow？
使用 GitHub flow 的基本要求有：
- 具备一个代码版本控制环境；
- 具备一个持续集成环境；
- （可选）具备 CI 环境的管理员权限；
- 能够创建一个有权限访问 VCS 平台的机器人帐号；
- 能够自由使用 VCS 平台的 WebHook API；
- 能够自由使用 CI 平台的 Trigger API；
- （可选）能够自由使用 CI 平台的状态查询 API；
- 能够创建一个高可用的内部服务器用于机器人帐号的运行；
- 能够决定开发团队的工作流程；
- 能够投入成本改善基础设施；
遗憾的是，我至今没有过这种条件，如果你有能力去实践 GitHub flow，希望能够珍惜这次改善开发体验的机会，让更多人了解这种流程优化带来的巨大效率优势。
如果有任何具体的技术问题，也欢迎进一步的讨论。
写在最后
以我个人的体验，GitHub flow 是 世界上唯一的真理 真正能够拯救开发效率的敏捷实践，将开发人员真正从体力劳动中解放出来，从而能够专注于学习与思考。
如果你也觉得 GitHub flow 真正拯救了你的项目开发，不妨将它继续推广下去。