从 GitLab Flow 到 Pipeline：分支策略 + CI/CD + 运维一文打通

"GitLab Flow 怎么落地""Pipeline 怎么配""GitLab 常用操作有哪些"------这些问题的答案其实是同一条链路：用对分支策略，配好流水线，再掌握日常运维操作。本文按"分支策略 → 流水线 → 日常运维"三段式讲透，覆盖研发团队最常用的极狐GitLab 用法。

第一部分：GitLab Flow 分支策略

为什么需要分支策略

Git 本身不规定工作流，团队如果各写各的，仓库很快就会乱成一团。GitLab 官方文档提供了功能分支工作流的推荐实践：所有开发在独立分支进行，通过合并请求（Merge Request）评审后合入主分支。

GitLab Flow 的核心思想是上游优先 ：一切变更先从主分支（默认 main）派生功能分支，完成后合回 main，再由 main 向下游分支流转。

GitLab Flow 的三种典型模式

模式一：持续发布（适合可随时上线的 Web 服务）

只保留一个主分支 main，功能分支合入后直接部署到生产。适合 CI/CD 成熟、发布无窗口限制的团队。

bash 复制代码

# 从 main 派生功能分支
git checkout -b feature/login main

# 开发完成后合回 main，触发流水线自动发布
git checkout main
git merge --no-ff feature/login
git push origin main

模式二：环境分支（适合有预发/生产环境的团队）

在 main 之外维护环境分支，如 staging、pre-production、production。变更按"上游优先"逐级向下游合并，保证每级环境都经过测试。

模式三：发布分支（适合有版本节奏的软件）

对外发布软件（如 App、客户端）时，从 main 拉发布分支（如 2-3-stable），只向发布分支合入严重修复，并按语义化版本打 tag。

分支策略配套：保护分支

无论哪种模式，都应该把长期分支设为受保护分支：禁止直接推送，变更必须走合并请求且通过审批。这是在极狐GitLab 中"规则化"分支策略的关键一步。

第二部分：Pipeline 流水线配置

最小可用的 .gitlab-ci.yml

在项目根目录创建 .gitlab-ci.yml，git push 即自动触发流水线。完整的语法参考极狐GitLab CI/CD 入门文档。

yaml 复制代码

stages:          # 阶段按顺序执行
  - build
  - test
  - deploy

build-job:       # 构建作业
  stage: build
  script:
    - echo "Compiling..."
    - docker build -t myapp:${CI_COMMIT_SHORT_SHA} .

test-job:        # 测试作业
  stage: test
  script:
    - echo "Running tests..."
    - pytest

deploy-job:      # 仅 main 分支合并后部署
  stage: deploy
  script:
    - echo "Deploying to production..."
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: on_success

常用内置变量说明：

CI_COMMIT_SHORT_SHA：当前提交的短哈希；
CI_COMMIT_BRANCH：当前分支名；
CI_PIPELINE_ID：流水线 ID。

流水线进阶三件套

CI/CD 变量：把密钥类信息放进项目/群组/实例级变量，支持自定义变量、预定义变量、受保护变量与掩码变量，避免硬编码进仓库；
CI/CD 表达式 ：使用 $[[ ]] 语法动态生成配置，支持 inputs context 与 matrix context；
CI/CD 组件 ：用 include:component 复用流水线配置片段，多项目共享同一套构建逻辑。

第三部分：日常运维操作

1. 创建用户与权限管理

管理员在"管理区域 → 用户 → 新建用户"创建账号，再把用户加入群组/项目并分配角色。极狐GitLab 的项目成员文档明确了角色模型：Guest（访客）、Reporter（报告者）、Developer（开发者）、Maintainer（维护者）、Owner（所有者）。

运维建议：按"最小权限"分配角色，长期分支设置保护，成员离职及时移除权限。

2. 删除仓库

删除项目在"设置 → 通用 → 高级 → 删除项目"中操作。注意：删除操作有 7 天延期期限，期间可以恢复。极狐GitLab 的项目删除是软删除，进入"延迟删除"状态，真正物理删除在期限到达后由系统执行。

安全提示：删除前确认仓库已有备份，且项目内没有其他人正在使用。

3. 备份与恢复

私有化部署实例的备份是运维刚需，官方提供完整的备份与恢复文档。

bash 复制代码

# 创建备份，归档默认生成在 /var/opt/gitlab/backups
sudo gitlab-backup create

# 恢复指定备份
sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq
sudo gitlab-backup restore BACKUP=<备份文件名>
sudo gitlab-ctl restart

建议通过 crontab 每日定时备份，并同步备份归档到异地存储。

4. 仓库镜像与迁移

需要同步仓库时，可在"设置 → 仓库 → 镜像仓库"中配置拉取/推送镜像，也可按官方导入文档从其他平台迁移项目。

一个综合示例：完整研发闭环

假设团队要做"登录功能"，完整链路是：

创建 Issue 描述需求；
从 main 派生分支 feature/login，开发代码并推送；
创建合并请求，流水线自动运行 build + test；
代码评审通过、流水线绿色，合入 main；
main 合并触发 deploy 作业，发布到生产；
生产问题通过日志定位，需要时用备份恢复数据。

这六步全部在极狐GitLab 内闭环，正是"分支策略 + 流水线 + 运维"组合起来的价值。

总结

分支策略：GitLab Flow 上游优先，用保护分支把规则固化；
流水线 ：.gitlab-ci.yml 声明式配置，变量/表达式/组件是进阶关键；
运维：创建用户、删除仓库、备份恢复三大高频操作，配合官方文档执行。

以上功能与命令均出自极狐GitLab 官方文档 docs.gitlab.cn 与官网 gitlab.cn，操作前建议以对应版本文档为准。

本文首发于极狐GitLab 官网技术资讯栏目。更多 GitLab 与 DevOps 实践，欢迎访问极狐GitLab 官网、官方中文文档中心，或前往 JihuLab.com 免费注册体验。