GitLab Workflow 流程简介

1. 背景

在过往，团队遵循的是 dev -> test -> demo -> master 这种单向的提交流程，这种提交流程的优点有如下几点：

• 适合快速的版本迭代
• 方便稳定的代码部署以及发布
• 保证了 demo 环境与 master 生产环境的代码一致性，更好的错误溯源，更少的系统性流程错误

但弊端也很明显，无法同时进行多个需求版本的开发。而在公司的组织架构变更的情况下，多个需求版本同时开发已然成为常态，团队要适应这种变化，只能修改 GitLab 的工作流程。

2. 团队Gitlab Workflow流程介绍

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

开发流程：

当新功能开发完成后，合并到 test 交付测试。测试通过后由 feature 分支直接合并到 demo 分支，在 demo 分支上完成验收工作。在完成这两个步骤之前，不应该将代码合并到其他分支。

当验收通过后，feature 分支上的代码再被合并到 master 分支上，由负责人评估代码影响范围，再部署上线。功能分支开发完成后由负责人负责删掉。

优点：

• 能适应复杂场景的发版需求

弊端：

• 流程有点复杂，与单向提交相比，稳定性较差。
• 在合并功能分支时，如有冲突，需要处理两次冲突（test一次，demo一次）

3. 简述分支作用

项目中存在：
三个基础分支（长期存在）：master 分支，demo 分支， test 分支；
两种流动分支（完成开发后会被删除）：feature 分支， hotfix 分支；

master 分支 —— 对应线上生产环境

master 分支存放所有正式发布的版本，可以作为项目历史版本记录分支，不直接提交代码，每次发版都需要打Tag，需要同步代码到其他正在开发的功能分支。

demo 分支 —— 对应演示环境

demo 分支作为测试和产品验收需求的分支，存放所有需要验收的功能代码，不直接提交代码，是由 feature 分支合并产生的。

test 分支 —— 对应功能测试环境

test 分支作为测试验证需求的分支，存放所有需要测试的功能代码，不直接提交代码，是由 feature 分支合并产生的。（test 分支和 demo 分支的主要区别是验收对象不一致）

feature 分支 —— 对应线上开发环境（如果存在的话）

feature分支为功能分支，每个功能分支都是基于 master 分支创建，功能开发完成后可合并到 test 分支，demo 分支，master 分支。

hotfix 分支

hotfix 分支为热修复分支，是基于 maste r分支创建，作用是对线上版本的 bug 进行修复。完成修复后直接合并到 master 分支。bug 完全修复后由负责人删掉。

4. 结尾

在开发过程中，需严格遵循代码提交流程，原则上不允许反向合并，比如从 test 分支合并到功能分支，因为如果 test 分支存在多个功能分支的代码，反向合并这个操作会污染当前的功能分支。

当然，如果现实中存在必须违反提交流程的情况，请与负责人联系。

下一章是项目示例。