📚 课程目录第3章 GitLab基础操作

3、GitLab基础操作：GitLab的安装与配置（Docker方式）、项目创建、分支管理、合并请求（MR）流程、代码审查与权限管理

GitLab作为业界领先的DevOps生命周期管理工具，不仅提供Git仓库托管能力，更内置了CI/CD流水线、代码审查、问题跟踪和权限治理等完整功能链。在持续集成课程体系中，GitLab是承载代码资产与协作流程的核心枢纽。本章将围绕Docker方式部署GitLab、项目与分支模型设计、合并请求（MR）协作规范以及权限管理四个维度展开，帮助学员建立从工具安装到团队协作治理的完整认知。

3.1 GitLab的Docker方式安装与配置

核心原理

GitLab由多个子系统组成（Rails应用、PostgreSQL数据库、Redis缓存、Gitaly存储、Nginx反向代理等）。Docker方式部署通过容器化将这些组件封装为统一镜像，大幅降低环境依赖冲突。生产环境推荐使用 docker-compose 编排，便于版本升级、数据卷挂载和日志收集。GitLab容器镜像基于Ubuntu，内部通过 gitlab-ctl reconfigure 完成初始配置。

操作流程

准备环境：确保Docker Engine ≥ 20.10，宿主机内存 ≥ 4GB（推荐8GB），磁盘 ≥ 50GB。
创建目录结构：

mkdir -p /srv/gitlab/{config,logs,data}
export GITLAB_HOME=/srv/gitlab

编写docker-compose.yml：

version: '3.8'
services:
  gitlab:
    image: gitlab/gitlab-ce:16.11.2-ce.0
    container_name: gitlab
    restart: always
    hostname: 'gitlab.example.com'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'http://gitlab.example.com:8929'
        gitlab_rails['gitlab_shell_ssh_port'] = 2224
        gitlab_rails['initial_root_password'] = 'StrongPassw0rd!'
        prometheus_monitoring['enable'] = false
    ports:
      - '8929:8929'
      - '2224:22'
    volumes:
      - '$GITLAB_HOME/config:/etc/gitlab'
      - '$GITLAB_HOME/logs:/var/log/gitlab'
      - '$GITLAB_HOME/data:/var/opt/gitlab'
    shm_size: '256m'

启动与验证：docker-compose up -d，等待3-5分钟执行 docker logs -f gitlab 观察初始化日志，访问 http://<服务器IP>:8929 使用root账号登录。

案例拆解：内存受限环境下的部署调优

某研发团队仅有4GB内存的云主机，直接启动GitLab导致频繁OOM。通过调整 GITLAB_OMNIBUS_CONFIG 降低资源占用：

postgresql['shared_buffers'] = "256MB"
postgresql['max_connections'] = 100
unicorn['worker_processes'] = 2
sidekiq['max_concurrency'] = 5
prometheus_monitoring['enable'] = false
gitlab_rails['env'] = { 'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000' }

调整后内存占用从3.8GB降至2.1GB，系统恢复稳定。注意：initial_root_password 仅在首次初始化时生效，后续修改需通过UI或 gitlab-rails console。

风险提示：切勿将 external_url 设置为 http://localhost，否则CI运行器无法通过域名访问GitLab实例。若使用自签名HTTPS证书，需在Runner注册时添加 --tls-ca-file 参数。

3.2 项目创建与分支管理策略

核心原理

GitLab中的项目（Project）是代码仓库、问题跟踪、CI/CD配置的集合体。分支管理策略决定了团队协作的流畅度与代码安全性。推荐采用 Git Flow 的简化变体：main 分支始终保持可发布状态，develop 分支集成开发成果，feature/* 分支承载具体功能开发。

操作流程

创建项目：登录GitLab → 点击"新建项目" → 选择"创建空白项目" → 填写项目名（如 order-service）、可见性（私有/内部/公开）、初始化README。
设置默认分支：进入项目 → 设置 → 仓库 → 将默认分支改为 develop，并添加 main 为受保护分支（仅Maintainer可推送）。
创建功能分支：

git clone git@gitlab.example.com:devops/order-service.git
cd order-service
git checkout -b feature/payment-gateway
git push -u origin feature/payment-gateway

分支策略对比表

策略类型	适用场景	优点	缺点
Git Flow	大型项目、固定发布周期	分支职责清晰，支持热修复	流程较重，长期维护多分支
GitHub Flow	持续部署、小型团队	极简，仅main+feature	对发布管理要求高
GitLab Flow	环境递进（dev→staging→prod）	与环境绑定，支持MR门禁	需严格规范环境分支

经验建议：对于微服务架构，建议每个服务独立项目，并使用 Group 分组管理。例如 devops/order-service、devops/user-service 同属 devops 组，便于统一设置成员权限和CI变量。

3.3 合并请求（MR）流程与代码审查

核心原理

MR是GitLab协作的核心机制，它将分支合并过程转化为可审查、可讨论、可自动检查的工作流。一个规范的MR应包含：清晰标题、关联Issue、变更描述、测试说明、审查人员指派。GitLab CI流水线可在MR创建时自动运行，作为合并的"质量门禁"。

标准MR流程

推送分支并创建MR，目标分支选择 develop。
填写MR描述：使用Markdown模板，包含变更目的、影响范围、测试步骤。
触发流水线：.gitlab-ci.yml中定义 test 阶段，运行单元测试与代码扫描。
指定Reviewer：至少1名高级开发或架构师。
讨论与修改：审查意见通过 git commit --amend 或新增commit解决。
合并：选择"合并提交"或"压缩合并"，删除源分支。

案例拆解：一次MR引发的流水线失败与修复

背景：前端团队在 feature/ui-refactor 分支重构登录页面，创建MR后流水线在 eslint 阶段失败。

现象：日志显示 error: 'authToken' is assigned a value but never used。

分析：重构时移除了旧接口调用，但未删除相关变量声明。ESLint规则 no-unused-vars 将其判定为error级别。

解决：开发者在本地执行 npm run lint -- --fix 自动清理，提交后重新推送，流水线通过。

复盘：团队在MR模板中增加"自检清单"，要求开发者推送前必须本地通过lint与单测。同时配置GitLab的 merge checks，强制要求流水线成功且至少1个批准才能合并。

代码审查要点清单：
逻辑正确性：边界条件、异常处理、并发安全。
安全性：SQL注入、XSS、敏感信息硬编码。
性能：N+1查询、大对象加载、缓存策略。
可维护性：命名规范、函数复杂度、重复代码。
测试覆盖：新增代码是否有对应单元测试。

3.4 权限管理与安全最佳实践

核心原理

GitLab采用基于角色的访问控制（RBAC），权限层级从高到低为：Owner（完全控制）、Maintainer（管理仓库+合并）、Developer（推送分支+创建MR）、Reporter（查看代码+创建Issue）、Guest（仅查看Issue）。权限可在 Group 或 Project 级别设置，子项目默认继承组权限。

权限配置操作

组权限：进入Group → 成员管理 → 邀请用户并选择角色。例如将测试人员设为Reporter，开发设为Developer。
项目权限：项目 → 设置 → 成员，可单独调整某成员在特定项目的角色。
保护分支：设置 → 仓库 → 保护分支，配置 main 分支仅Maintainer可推送，允许Developer合并MR。
代码所有者：在仓库根目录添加 CODEOWNERS 文件，指定特定路径的强制审查人。

权限模型对比表

角色	推送分支	创建MR	合并MR	管理CI/CD	管理成员
Guest	✗	✗	✗	✗	✗
Reporter	✗	✓	✗	✗	✗
Developer	✓	✓	✓（受保护分支除外）	✓	✗
Maintainer	✓	✓	✓	✓	✓
Owner	✓	✓	✓	✓	✓（含删除项目）

常见误区与总结复盘

误区1：所有成员设为Developer导致误操作。例如测试人员误推送代码到 develop 分支。
误区2：忽略组权限继承。当项目从组中继承权限后，在项目级别单独添加成员可能造成权限冗余。
误区3：保护分支设置不当。若将 develop 也设为仅Maintainer可推送，会阻塞开发者的常规提交流程。

总结复盘：权限管理的核心原则是最小权限与职责分离。建议定期使用GitLab的 审计事件 功能审查敏感操作（如权限变更、分支删除）。对于大型团队，可结合 SAML SSO 或 LDAP 实现统一身份认证，避免账号管理混乱。通过本章学习，学员应能独立完成GitLab的容器化部署，并设计出适合团队规模的分支与权限模型，为后续CI/CD流水线搭建奠定坚实基础。