GitLab 是什么？代码托管、Merge Request 和 CI/CD 怎么连成一套工作流

GitLab 真正省事的地方，是少在几个系统之间来回切

如果项目已经用 Git，GitLab 最容易理解的入口还是仓库。但实际工作里更常见的是：需求或 issue 进来，开分支改代码，用 Merge Request 做评审，再让流水线自动跑测试、构建和部署。代码、讨论和执行记录都能沿着同一条链路看下去。

Merge Request 不只是“点一下合并”

把 Merge Request 当成评审入口更合适。提交前先把改动范围写清楚，关联 issue，等自动检查跑完，再让评审者看关键差异。大改动拆小一点，通常比一个几千行的 MR 更容易发现问题，也更容易回滚。

CI/CD 从一个 .gitlab-ci.yml 开始，但别一上来写得太复杂

GitLab CI/CD 通过仓库根目录里的 .gitlab-ci.yml 定义 jobs 和 stages。刚开始先覆盖最值钱的几步，比如 lint、测试和构建；等流程稳定后再加部署、缓存或多环境。流水线越长，排错成本也越高。

团队要特别留意变量、权限和 Runner

API Key、部署密钥不要直接写进仓库；CI/CD Variables、受保护分支和 Runner 权限要跟项目敏感度一起设计。自建 Runner 还要考虑补丁、网络和隔离，不能因为“跑在自己机器上”就默认更安全。

什么时候 GitLab 比单纯代码托管更合适

如果你只需要一个远程 Git 仓库，很多平台都能做；如果团队希望把代码评审、流水线、权限和项目协作尽量收在一起，GitLab 的价值才更明显。最终选型还是要看现有团队习惯和部署环境。