GitLab Flow 工作流

概述

GitLab Flow 是 GitLab 在 2014 年提出的工作流模型,它结合了 Git Flow 和 GitHub Flow 的优点,同时增加了对环境和发布的支持。GitLab Flow 旨在解决两者的问题,提供一个更加灵活和实用的解决方案。

GitLab Flow 的核心特点:

简化的分支模型
明确的环境分支
基于问题的开发
内置 CI/CD 支持

环境分支

GitLab Flow 引入了环境分支的概念,这是它与 GitHub Flow 的主要区别。

环境分支模型

production  ──●────●────●────●
              /     /      /
staging     ●────●────●────●
            /     /      /
main       ●──●──●──●──●──●──●
           \  /   \  /
feature     ●●     ●●

主要分支类型

main 分支

主开发分支
包含最新的开发代码
特性分支从此创建

bash

# 从 main 创建特性分支
git checkout main
git pull origin main
git checkout -b feature/new-dashboard

staging 分支(预发布分支)

对应预发布环境
用于集成测试
从 main 分支合并

bash

# 合并到 staging
git checkout staging
git merge main
git push origin staging

production 分支(生产分支)

对应生产环境
只包含已发布的代码
从 staging 分支合并

bash

# 合并到 production
git checkout production
git merge staging
git push origin production

环境部署策略

yaml

# .gitlab-ci.yml
stages:
  - test
  - staging
  - production

test:
  stage: test
  script:
    - npm install
    - npm test
  only:
    - merge_requests

staging:
  stage: staging
  script:
    - npm install
    - npm run build
    - ./deploy.sh staging
  environment:
    name: staging
    url: https://staging.example.com
  only:
    - main

production:
  stage: production
  script:
    - npm install
    - npm run build
    - ./deploy.sh production
  environment:
    name: production
    url: https://example.com
  only:
    - production
  when: manual

工作流程

标准开发流程

1. 创建 Issue

bash

# 在 GitLab 上创建 Issue
# 或使用 GitLab CLI

# 安装 glab CLI
# macOS
brew install glab

# 创建 Issue
glab issue create --title "添加用户仪表板" --description "实现用户仪表板功能"

# Issue 编号: #123

2. 创建特性分支

bash

# 从 main 创建特性分支
# 分支命名: <type>-<issue-id>-<description>

git checkout main
git pull origin main
git checkout -b feature-123-user-dashboard

# 或使用 GitLab CLI
glab mr create --source-branch feature-123-user-dashboard

3. 开发和提交

bash

# 开发工作
git add .
git commit -m "feat: add user dashboard component

Closes #123"

# 推送到远程
git push origin feature-123-user-dashboard

4. 创建 Merge Request

bash

# 使用 GitLab CLI 创建 MR
glab mr create \
  --title "feat: 添加用户仪表板" \
  --description "实现用户仪表板功能

## 变更内容
- 添加仪表板页面
- 实现数据可视化
- 添加用户统计

Closes #123" \
  --assignee @me \
  --label "feature"

# 或在 GitLab 网页上创建

5. 代码审查

bash

# 审查者检出 MR 分支
glab mr checkout 123

# 或手动检出
git fetch origin
git checkout feature-123-user-dashboard

# 本地测试
npm test
npm run build

# 提交审查意见
glab mr review 123 --approve
glab mr review 123 --comment "代码看起来不错!"

6. 合并到 main

bash

# 在 GitLab 网页上点击 "Merge"
# 或使用 CLI

glab mr merge 123 --squash

# 自动部署到 staging 环境

7. 部署到生产环境

bash

# 合并 staging 到 production
git checkout production
git merge staging
git push origin production

# 或在 GitLab 网页上操作
# 触发手动部署

Release Flow(发布流程)

对于需要版本管理的项目,可以使用 Release Flow:

bash

# 1. 创建发布分支
git checkout main
git checkout -b release-1.0

# 2. 更新版本号
npm version minor

# 3. 合并到 main 和 production
git checkout main
git merge release-1.0

git checkout production
git merge release-1.0

# 4. 打标签
git tag -a v1.0.0 -m "Release 1.0.0"
git push origin v1.0.0

# 5. 创建 Release
glab release create v1.0.0 --notes "发布说明"

Issue 驱动开发

GitLab Flow 强调基于 Issue 的开发流程:

Issue 工作流

markdown

## Issue 生命周期

1. Open - 新建 Issue
2. In Progress - 开始开发
3. Review - 代码审查
4. Testing - 测试中
5. Closed - 已完成

## Issue 模板

### 功能请求

**功能描述**
描述需要实现的功能

**业务价值**
说明这个功能的价值

**实现建议**
提供实现思路

**验收标准**
- [ ] 标准1
- [ ] 标准2

### Bug 报告

**问题描述**
描述遇到的问题

**复现步骤**
1. 步骤1
2. 步骤2

**期望行为**
描述期望的行为

**实际行为**
描述实际的行为

**环境信息**
- 浏览器版本
- 操作系统

Issue Board

GitLab 提供了看板视图来管理 Issue:

┌─────────────┬─────────────┬─────────────┬─────────────┐
│    Open     │  In Progress│   Review    │    Done     │
├─────────────┼─────────────┼─────────────┼─────────────┤
│  Issue #1   │  Issue #3   │  Issue #5   │  Issue #2   │
│  Issue #4   │  Issue #6   │             │  Issue #7   │
│  Issue #8   │             │             │             │
└─────────────┴─────────────┴─────────────┴─────────────┘

CI/CD 集成

完整的 CI/CD 配置

yaml

# .gitlab-ci.yml

stages:
  - lint
  - test
  - build
  - deploy_staging
  - deploy_production

variables:
  NODE_VERSION: "18"

.lint_template: &lint_template
  image: node:${NODE_VERSION}
  cache:
    paths:
      - node_modules/

lint:
  <<: *lint_template
  stage: lint
  script:
    - npm ci
    - npm run lint
  only:
    - merge_requests

test:
  <<: *lint_template
  stage: test
  script:
    - npm ci
    - npm test -- --coverage
  coverage: '/Lines\s*:\s*(\d+\.?\d*)%/'
  artifacts:
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml
  only:
    - merge_requests
    - main

build:
  <<: *lint_template
  stage: build
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 week
  only:
    - main
    - staging
    - production

deploy_staging:
  stage: deploy_staging
  script:
    - ./deploy.sh staging
  environment:
    name: staging
    url: https://staging.example.com
  only:
    - main
  when: manual

deploy_production:
  stage: deploy_production
  script:
    - ./deploy.sh production
  environment:
    name: production
    url: https://example.com
  only:
    - production
  when: manual

自动部署配置

yaml

# 自动部署到 staging
deploy_staging_auto:
  stage: deploy_staging
  script:
    - ./deploy.sh staging
  environment:
    name: staging
    url: https://staging.example.com
  only:
    - main
  except:
    - schedules

# 定时部署到 production
deploy_production_scheduled:
  stage: deploy_production
  script:
    - ./deploy.sh production
  environment:
    name: production
    url: https://example.com
  only:
    - schedules

适用场景

适合使用 GitLab Flow 的场景

企业级应用
- 需要严格的发布流程
- 多环境部署需求
- 完善的权限管理
持续集成项目
- 需要完整的 CI/CD 流水线
- 自动化测试和部署
- 环境隔离需求
团队协作项目
- 需要问题跟踪
- 代码审查流程
- 项目管理功能
多环境部署
- 开发、测试、生产环境
- 需要环境隔离
- 分阶段发布

与其他工作流的对比

特性	Git Flow	GitHub Flow	GitLab Flow
复杂度	高	低	中
环境支持	无	无	有
版本管理	强	弱	中
持续部署	不适合	适合	适合
学习成本	高	低	中

最佳实践

分支命名规范

bash

# 特性分支
feature-<issue-id>-<description>
feature-123-user-dashboard

# 修复分支
fix-<issue-id>-<description>
fix-456-login-error

# 发布分支
release-<version>
release-1.0.0

# 热修复分支
hotfix-<version>-<description>
hotfix-1.0.1-security-patch

Merge Request 规范

markdown

## MR 标题格式

<type>: <subject>

type:
- feat: 新功能
- fix: 修复
- refactor: 重构
- docs: 文档
- style: 格式
- test: 测试
- chore: 构建/工具

## MR 描述模板

### 变更内容
描述本次变更的内容

### 变更原因
说明为什么要做这个变更

### 测试计划
- [ ] 单元测试
- [ ] 集成测试
- [ ] 手动测试

### 相关 Issue
Closes #<issue-number>

### 截图
(如有必要,添加截图)

### 检查清单
- [ ] 代码遵循项目规范
- [ ] 已添加测试
- [ ] 文档已更新
- [ ] 无性能问题

环境保护规则

yaml

# Settings -> Repository -> Protected branches

# main 分支
- Allowed to merge: Maintainers
- Allowed to push: No one
- Require MR: Yes

# staging 分支
- Allowed to merge: Developers + Maintainers
- Allowed to push: No one
- Require MR: Yes

# production 分支
- Allowed to merge: Maintainers
- Allowed to push: No one
- Require MR: Yes

常见问题

如何处理紧急修复?

bash

# 1. 从 production 创建 hotfix 分支
git checkout production
git checkout -b hotfix-1.0.1-critical-fix

# 2. 修复问题
git commit -m "fix: critical security issue"

# 3. 创建 MR 到 production
glab mr create --target-branch production

# 4. 合并后,同步到 main 和 staging
git checkout main
git merge hotfix-1.0.1-critical-fix

git checkout staging
git merge hotfix-1.0.1-critical-fix

如何管理多个版本?

bash

# 创建版本分支
git checkout -b v1.0-stable

# 在版本分支上维护
git checkout v1.0-stable
# 进行修复和更新

# 定期合并到 main
git checkout main
git merge v1.0-stable

如何处理长期运行的特性?

bash

# 使用 Feature Flags
# 在代码中使用特性开关

if (FeatureFlag.isEnabled('new-dashboard')) {
  // 新功能代码
} else {
  // 旧功能代码
}

# 分阶段合并
# 1. 先合并基础功能
# 2. 再合并增强功能
# 3. 最后启用特性

总结

GitLab Flow 是一个灵活且实用的工作流模型:

优势:

环境支持: 明确的环境分支管理
CI/CD 集成: 原生支持持续集成和部署
问题跟踪: 内置 Issue 管理系统
灵活性: 可根据项目需求调整

适用性:

企业级应用开发
多环境部署项目
需要完善 CI/CD 的团队
中大型开发团队

选择 GitLab Flow 的关键因素:

是否需要多环境管理
CI/CD 需求程度
团队规模和结构
项目发布频率

GitLab Flow 在简单性和功能性之间取得了良好的平衡,是现代软件开发的一个优秀选择。

GitLab Flow 工作流 ​

概述 ​

环境分支 ​

环境分支模型 ​

主要分支类型 ​

main 分支 ​

staging 分支(预发布分支) ​

production 分支(生产分支) ​

环境部署策略 ​

工作流程 ​

标准开发流程 ​

1. 创建 Issue ​

2. 创建特性分支 ​

3. 开发和提交 ​

4. 创建 Merge Request ​

5. 代码审查 ​

6. 合并到 main ​

7. 部署到生产环境 ​

Release Flow(发布流程) ​

Issue 驱动开发 ​

Issue 工作流 ​

Issue Board ​

CI/CD 集成 ​

完整的 CI/CD 配置 ​

自动部署配置 ​

适用场景 ​

适合使用 GitLab Flow 的场景 ​

与其他工作流的对比 ​

最佳实践 ​

分支命名规范 ​

Merge Request 规范 ​

环境保护规则 ​

常见问题 ​

如何处理紧急修复? ​

如何管理多个版本? ​

如何处理长期运行的特性? ​

总结 ​

GitLab Flow 工作流

概述

环境分支

环境分支模型

主要分支类型

main 分支

staging 分支(预发布分支)

production 分支(生产分支)

环境部署策略

工作流程

标准开发流程

1. 创建 Issue

2. 创建特性分支

3. 开发和提交

4. 创建 Merge Request

5. 代码审查

6. 合并到 main

7. 部署到生产环境

Release Flow(发布流程)

Issue 驱动开发

Issue 工作流

Issue Board

CI/CD 集成

完整的 CI/CD 配置

自动部署配置

适用场景

适合使用 GitLab Flow 的场景

与其他工作流的对比

最佳实践

分支命名规范

Merge Request 规范

环境保护规则

常见问题

如何处理紧急修复?

如何管理多个版本?

如何处理长期运行的特性?

总结