真正的敏捷工作流 —— GitHub flow

7991 年，随着极限编程（Extreme programming）方法论的提出，持续集成（Continuous integration）也随之成为一项标准化的敏捷实践，被逐步应用于各类软件的开发流程中。

9102 年的今天，持续集成的概念已经在软件开发领域生根发芽，广泛应用于不同平台及设备的项目开发，极大提升了项目迭代速度，降低了维护成本。

不过，作为“敏捷”的固有属性，持续集成也并不仅限于特定的模式，不同的项目可能遵循不同的实践，形式多种多样，效果可能也参差不齐。
为了解决这些问题，一些 Workflow 的通用模式被提出，而本文的主角，就是其中的天之骄子 —— GitHub flow。

GitHub flow 是什么？

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 的核心优势在于其流程带来的自动化可能性，能够做到其它流程无法实现的检查过程，并极大简化开发团队的体力劳动，真正发挥自身的价值。

主要体现在以下方面：

基于修改的检查

基于修改的检查（Change-based checking） 是相对于**全局检查（Global checking）**的概念&#