GitHubFlow及GitLabFlow简明教程

一、GitHub Flow

1.1 简介

在原先的文章《Git Flow简明教程》中，我们已经看到了，GitFlow中分支比较多，不太适合持续发布的开发场景。持续发布，就是指随时提交，随时发布，不需要等待某个特定的时间或者版本。

GitHubFlow对GitFlow做了简化，专门适用于持续发布的开发流程。它只维护一个长期分支master，其它的无论是做什么用途的分支都算临时分支，用完即删除。如此，无论何时发布master，其都是最新的内容。

1.2 使用说明

master分支是默认就拥有的，我们不能在其上进行开发，因此需要创建一个单独的分支用于开发：

git branch -b feature-xxx master

当内容开发完成，并且确定不再需要新增或者修改后，就可以将内容合并到master上：

git checkout master

git merge feature-xxx

此时，master上就会随时都包含最新的内容，随时都可以进行发布操作，完美契合持续发布流程。随后我们就可以将先前的临时分支删除：

git branch -d feature-xxx

1.3 优缺点分析

• 需要维护长期分支数目较少，简单容易操作；
• 天然契合持续发布的工作流程；
• 不适用于版本发布的工作流程；

二、GitLab Flow

2.1 简介

GitLab Flow是吸收了Git Flow和GitHub Flow的优点，遵循“上游优先”的策略，做到既简单容易操作，又能满足不同的工作流程。

2.2 持续发布使用说明

持续发布的场景要求我们随时都有最新的内容发布到生产，因此我们还是保留一个master长期分支，它作为其它任何分支的上游分支，然后再分别创建一个预发布分支pre-production和发布分支production：

git checkout -b pre-productionxxx master

git checkout -b productionxxx master

其中，预发布分支pre-production是用来检测master上的更新内容是否具有风险和Bug的，如果没有问题，则直接再合并到production上，进行发布即可。

git checkout pre-productionxxx

git merge master

git checkout productionxxx

git merge pre-productionxxx

如此，可以实现使用GitLab Flow来实现持续发布的工作流程。

2.3 版本发布使用说明

每一个稳定的版本都单独作为一个分支存在，从master上拉取出来。以后只有master上的Bug修复才会被允许cherry-pick到这些单独的版本分支上，而对于master上的新内容是不采取合并操作的：

git checkout -b stable1 master

如上创建了稳定版本stable1分支后，master可以继续接受来自其它分支的合并内容，但这些内容和stable1分支没有关系，因为stable1分支是某个具体的版本，只包含固定的内容。只有那些发现了存在于stable1上的Bug，才会需要从master合并到stable1上。

为什么我们不把Bug修复的内容直接提交到stable1上，别忘了GitLab Flow遵循的上游优先策略，我们只有先合并到master上，才能再从master上合并到stable1上：

git cherry-pick 提交号

如上，就可以实现使用GitLab Flow来实现版本发布的工作流程，大致示意图如下：

cherry-pick版本发布示意

2.4 优缺点分析

• 兼具GitFlow和GitHubFlow的优点，既能够满足持续发布又可以做到版本发布；
• 只有一个长期分支master，方便简洁容易操作；
• 支持使用cherry-pick对已经发布的稳定版本在不增加内容的情况下，修复Bug；
• 需要自己区分使用场景；