『前端进阶』—— 代码管理方案之GitLab Flow

前言

当你往高级前端进阶的过程中，避免不了要带领团队负责一个项目，此时你必定会遇到一个头疼的问题，代码如何进行管理。一般我们都使用Git来管理代码，业界中提供了几种Git工作流，每一种Git工作流就是一种代码管理方案，在对这几种Git工作流的流程熟悉后，才能给团队提供一种合适的代码管理方案。

本文将详细介绍其中一种Git工作流——GitLab Flow，希望对你有帮助，也欢迎在评论中讨论。

一、流程概念图

先上一张流程概念图，按图给你介绍GitLab Flow。

二、开发流程

GitLab Flow 的最大原则叫做”上游优先”（upsteam first），即只存在一个主分支master，它是所有其他分支的”上游”。只有上游分支采纳的代码变化，才能应用到其他分支。

故开发新功能前，要用分支master创建一个开发新功能的分支，分支的名称可以用功能名称来命名，这里先给这个分支命名为feature。

当功能开发完成后，用分支master去合并分支feature，合并完成后将分支feature删除。

三、测试流程

将分支master的代码部署到测试环境，测试出BUG，直接在分支master上修复，修复完成后部署到测试环境进行测试。

四、预发布流程

分支master的代码测试通过后，用分支master创建出一个分支，命名为pre-production。分支pre-production就是预发布分支，将其部署到预发布环境。

五、修复预发布环境BUG流程

预发布的代码出现BUG时，由于要遵循“上游优先”，不能直接在分支pre-production上修复BUG，得用分支pre-production创建出一个修复BUG的分支，分支的名字可以用BUG名称来命名，这里先给这个分支命名为fixbug。

将BUG修复后，用分支master合并分支fixbug，将分支master的代码部署到测试环境进行测试。

若没有通过测试，继续在分支fixbug上修复BUG，修复后再用分支master合并分支fixbug，再把分支master的代码部署到测试环境进行测试，直到BUG被修复。

BUG被修复后，用分支pre-production合并分支fixbug，然后将分支pre-production的代码部署到预发布环境进行测试，若测试通过则BUG修复完毕，删除分支fixbug，若测试不通过重复以上步骤。

六、正式环境发布流程

遵循“上游优先”原则，要用预发布分支pre-production创建出一个分支，命名为production。分支production就是正式分支，将其部署到正式环境，即完成正式环境发布流程。

七、修复正式环境BUG流程

遵循“上游优先”原则，得用分支production创建出一个修复BUG分支，分支的名字可以用BUG名称来命名，这里先给这个分支命名为fixbug。

在BUG修复后，在本地测试通过后，用分支master合并分支fixbug，将分支master的代码部署到测试环境进行测试。

若没有通过测试，继续在分支fixbug上修复BUG，再用分支master合并分支fixbug，将分支master的代码部署到测试环境进行测试，直到BUG被修复。

BUG修复后，要遵循“上游优先”原则，故要先把代码发到预发布环境进行测试，测试通过后才能发布到正式环境。

那么用分支pre-production合并分支fixbug。然后将分支pre-production的代码部署到预发布环境进行测试。

若测试通过，用分支production合并分支fixbug，然后部署到正式环境，删除分支fixbug。

若测试失败，重新回到分支fixbug修复BUG，继续走上面的流程，直到Bug被修复。

八、版本发布流程

在GitLab Flow 中版本发布不是采用打tag的形式。而是要用分支master创建一个分支，分支的名字可以如上图那样命名，比如2-3-stable、2-4-stable等等，要注意此时的分支master上的代码是稳定。

若版本分支的代码出现BUG，还是要在分支master上修复BUG，BUG被修复且通过测试后，在版本分支上执行命令git cherry-pick commitId，其中commitId是分支master上BUG修复的提交commitId，将修复BUG的代码合并到版本分支上，再将代码部署到对应的环境。