GitLab 从入门到上手：新手必看的基础操作 + 企业级应用指南

前言

大家好，我是 3Katrina，最近我有幸进入到了小米前端的实习岗位，目前还处于最开始的一两天。

坐上工位的前两天，除了学习 macOS 的基础操作（比如快捷键、终端使用等），我发现最急需掌握的工具就是 GitLab------ 毕竟后面的任务涉及代码同步和协作，不懂它几乎寸步难行。

这篇文章就来梳理我对 GitLab 的初步理解和简单使用方法：没有复杂的底层原理，全是新手能直接套用的实用内容。不论是你当下正在接触公司业务，还是未来准备进入实习阶段，我相信看完这篇文章，都能帮你快速上手 GitLab，少走一些弯路。

先聊聊 GitHub：熟悉的 "老朋友"

提到代码托管工具，很多同学最先接触的应该是 GitHub。我自己在学习前端的过程中，也经常用 GitHub 存个人项目、 fork 开源代码，对它还算熟悉。

简单回顾下 GitHub 的核心价值：它是一个基于 Git 的公共代码托管平台，核心功能包括：

版本控制：记录代码的每一次修改，随时回滚到历史版本；
协作开发：多人可以共同维护一个仓库，通过分支、PR（Pull Request）配合工作；
生态丰富：有大量开源项目可供学习，还能绑定 CI/CD 工具实现自动化部署。

但大家要注意：会用 GitHub 不等于能直接上手 GitLab。虽然两者都基于 Git，核心逻辑（如分支、提交、合并）一致，但 GitLab 更偏向 "企业内部使用"，功能设计、权限管理、协作流程都和面向公众的 GitHub 有明显区别，所以接下来重点拆解 GitLab。

GitLab 的初步理解：企业级的 "代码管家"

如果用一句话形容 GitLab，我觉得它是为企业团队量身打造的 "代码管理 + 协作办公一体化平台" 。它不只是 "存代码的地方"，更像是团队开发的 "中枢系统"------ 从需求提报、代码编写，到测试、部署，整个开发流程都能在 GitLab 上完成。

对新手来说，不用一开始就掌握所有功能，先记住它的 3 个核心定位，就能建立基本认知：

代码的 "安全仓库" 和 GitHub 类似，GitLab 最基础的功能是存储代码，但它多了 "企业级安全管控"。比如公司内部项目会设置 "私有仓库"，只有被授权的同事才能访问；还能限制谁能修改代码、谁只能查看，避免核心代码泄露或误操作。
团队的 "协作中枢" 实习后我发现，前端、后端、测试同事都在同一个 GitLab 项目下协作：我写的前端代码要通过 "MR（Merge Request，合并请求）" 提交，后端同事会在 MR 里看接口是否匹配，测试同事会在上面提 Bug 反馈 ------ 所有人的沟通和修改都能留痕，不用再反复发文件、微信群里丢链接，效率高很多。
开发的 "流程管家" 这是 GitLab 和 GitHub 差异最大的一点：它能串联起整个开发流程。比如在 GitLab 上可以直接创建 "需求工单"（记录要开发的功能）、"Bug 工单"（记录要修复的问题），代码提交后还能自动触发测试脚本（比如 ESLint 检查、单元测试），甚至直接部署到测试环境 ------ 相当于把 "写代码" 之外的很多琐事都自动化了。

GitLab 仍然是基于 Git：核心逻辑不变，不用怕！

虽然 GitLab 功能多，但大家不用有心理负担 ------ 它的 "底层骨架" 还是 Git，核心操作逻辑和 GitHub 完全一致。只要你之前用过 Git 命令（比如 git add、git commit、git push），上手 GitLab 会快很多。

这里帮新手梳理几个 "不变的核心概念"，先把基础打牢：

概念	作用（新手视角）
仓库（Repository）	存放一个项目的所有代码和资源（比如前端项目的 HTML、CSS、JS 文件），相当于 "项目文件夹"。
分支（Branch）	代码的 "平行宇宙"：比如在 "dev" 分支写新功能，不影响 "main"（主分支）的稳定代码。
提交（Commit）	记录代码的一次修改，每次提交会生成一个唯一 ID，方便后续回滚或查看历史。
合并（Merge）	把一个分支的代码合并到另一个分支（比如功能开发完后，把 "dev" 分支合并到 "main" 分支）。

简单说：Git 是 "版本控制的工具"（底层技术），GitLab 是 "基于 Git 的平台"（把 Git 封装成更易用的工具，并加了很多企业功能）。所以先巩固 Git 基础，再学 GitLab 的操作，会事半功倍。

GitLab是企业级的

前面提到 "GitLab 是企业级的"，这不是一句空话 ------ 体现在实际使用中，有几个和 GitHub 不同的 "关键点"，新手必须提前了解，否则很容易踩坑：

1. 权限管理更严格："不是所有人都能改代码"

GitHub 上的公共仓库，只要你 Fork 后就能提交 PR；但 GitLab 企业项目里，权限细分非常细，不同角色能做的操作完全不一样。

比如我作为实习生，一开始只有 "开发者（Developer）" 权限：可以拉取代码、在指定分支提交代码，但不能直接合并到主分支（main）；而我的导师有 "维护者（Maintainer）" 权限，才能审核我的 MR 并合并。

下面是几个常见的权限角色（不同公司可能有调整）：

访客（Guest）：只能查看项目，不能修改代码；
Reporter（报告者）：能提工单、看代码，但不能提交修改；
开发者（Developer）：能提交代码、创建分支，但不能合并到保护分支（如 main）；
维护者（Maintainer）：能审核 MR、合并代码、管理分支权限；
所有者（Owner）：能管理整个项目，包括添加成员、修改权限。

2. 协作流程更规范："按公司规则走，不能自己随便改"

GitHub 上个人项目的流程很灵活，你想直接在 main 分支改代码也没人管；但企业用 GitLab 时，都会有固定的 "协作流程"，必须严格遵守。

以我在小米前端的流程为例，基本是这样的（新手可以参考）：

从 "dev"（开发分支）创建自己的 "功能分支"，比如 feature/login-page（命名要清晰，让人一看就知道是做什么的）；
在自己的分支上写代码，每次修改后用 Git 提交并推到 GitLab；
功能写完后，在 GitLab 上创建 "MR"，指定合并到 "dev" 分支，并 @导师和相关同事审核；
审核通过（比如代码没 bug、符合规范）后，由维护者合并代码；
合并后，自己的功能分支就可以删除了，避免仓库里分支过多。

这种流程的好处是 "权责清晰"，每个修改都有审核，减少出错概率 ------ 新手一定要先问清楚团队的流程，不要自己随便创建分支或提交 MR。

3. 额外功能更实用："不止于代码，能管整个开发流程"

GitLab 除了代码管理，还内置了很多企业需要的功能，这些是 GitHub 没有（或需要额外配置）的，新手可以慢慢探索：

工单系统（Issues） ：用来记录需求、Bug、任务，比如产品经理提 "需要加一个登录弹窗"，会在 Issues 里写清楚需求，我开发时就盯着这个工单做，不用反复沟通；
CI/CD 流水线（Pipelines） ：代码提交后，GitLab 会自动跑 "流水线"------ 比如先检查代码规范（ESLint），再跑单元测试，最后把代码部署到测试环境，全程不用手动操作；
Wiki 文档：项目的技术文档可以直接存在 GitLab 上，比如接口文档、部署步骤，不用再单独找地方存（我现在查后端接口，直接看项目的 Wiki 就够了）。

GitLab 新手必学的 5 个基础操作（附步骤）

理解了概念后，最关键的是 "动手用起来"。这里整理我入职后最常用的 5 个操作，步骤尽量写得简单，新手跟着做就能上手：

1. 从 GitLab 拉取代码到本地（第一次获取项目）

刚入职时，导师会给你 GitLab 项目的链接，第一步就是把代码拉到自己的电脑上：

打开 GitLab 项目页面，点击右上角的 "Clone"，复制 "HTTPS" 链接（比如 https://gitlab.xxx.com/mi/frontend-project.git）；
打开本地终端，进入你想存放项目的文件夹（比如 cd /Users/yourname/Documents/work）；
输入命令 git clone 刚才复制的链接，按回车 ------ 等待片刻，代码就会下载到本地了。

2. 创建自己的功能分支（避免影响主分支）

拉取代码后，不要直接在 main 或 dev 分支上改，要创建自己的分支：

先进入项目文件夹：cd frontend-project；
确保当前分支是最新的（比如先切到 dev 分支）：git checkout dev；
创建并切换到自己的功能分支：git checkout -b feature/your-feature-name（比如 git checkout -b feature/login-modal）；
- 分支命名建议：类型/功能名，类型可以是 feature（新功能）、bugfix（修 Bug）、hotfix（紧急修复）。

3. 提交代码到本地 Git，再推到 GitLab

写好代码后，要把修改提交到 GitLab 上：

查看自己修改了哪些文件：git status（红色的是未提交的文件）；
把修改的文件加入 "暂存区"：git add 文件名（如果想加所有文件，用 git add .）；
提交到本地 Git，写清楚修改内容：git commit -m "feat: 新增登录弹窗组件，支持手机号验证"；
- 提交信息建议：类型: 描述，类型和分支类型对应（feat、fix 等），描述要简洁明了；
推到 GitLab 对应的分支：git push origin 你的分支名（比如 git push origin feature/login-modal）。

4. 在 GitLab 上创建 MR（请求合并代码）

代码推到 GitLab 后，需要创建 MR，让导师或同事审核：

打开 GitLab 项目页面，会自动提示 "有新的分支，是否创建 MR"，点击 "Create merge request"；
填写 MR 信息：
- "Source branch" 选你自己的分支（比如 feature/login-modal）；
- "Target branch" 选要合并到的分支（比如 dev，问清楚团队规定）；
- "Title" 写 MR 主题（和 commit 信息类似，比如 "新增登录弹窗组件"）；
- "Description" 写清楚你做了什么修改、需要注意什么（比如 "弹窗用了 Vue3 的 Teleport，适配了移动端"）；
勾选 "Assignee"（审核人，选你的导师或负责人），再点击 "Create merge request"------ 这样审核人就会收到通知了。

5. 审核通过后，删除本地分支（保持整洁）

当你的 MR 被审核通过并合并到目标分支（如 dev）后，自己的功能分支就没用了，记得删除：

先切回 dev 分支，并拉取最新的代码（包含你刚合并的内容）：git checkout dev && git pull；
删除本地的功能分支：git branch -d 你的分支名（比如 git branch -d feature/login-modal）；
- 如果提示 "分支未合并"，但你确认已经合并了，可以用 git branch -D 分支名 强制删除。

GitLab的企业级应用

上面的内容是偏新手向的，下面介绍下GitLab在企业上的应用，包括私有化部署、.gitlab-ci.yml，CI/CD，runner等内容，看完了下面的内容能够让你对GitLab有个更加立体的了解！

私有化部署

我们作为个人开发者，每次创建项目，管理项目等都是提交到自己的仓库，实际上这个仓库是github或者gitlab本身的服务器在帮我们管理，他是公共的，意味着我们提交的仓库我们经常所说的"开源的"，这固然很好，为全球数以万计的开发者们提供了便利，得到了免费的项目管理！

但是作为一个企业来讲，它的核心项目往往是不希望开源的，这很可能会带来竞争对手的查看，从而失去一些独特竞争力，所以企业的大型项目肯定是不能直接放在github或者gitlab这样的平台上的，它需要有自己的服务器来进行管理着项目，而且同样又需要具备管理项目的功能，让一个项目团队中的各个成员能够进行提交、审核、合并。

而gitlab正是提供了这样的功能，使得让企业内部管理着整个项目，不暴露出去，只有指定权限的人才能看得到，动的了，这个功能正是私有化部署！

它的特点是：

绝对的私密性：项目不会暴露在公网，只有企业内部授权人员才能访问；
严格的权限管控：可以精细设置谁能查看代码、谁能提交修改、谁能审批合并，确保每一步操作都在可控范围内；
数据自主掌控：代码和协作数据完全由企业自己管理，不用担心平台故障、政策变动等外部因素影响；
贴合企业流程：可以根据内部开发规范，定制分支策略、审核流程、自动化工具链等，让平台真正适配企业需求。

简单说，私有化部署让企业拥有了一个 "量身定制的内部 GitLab"------ 既保留了代码托管和团队协作的核心功能，又筑起了一道保护商业机密的安全屏障，这也是大型企业、涉密机构等对代码安全有高要求的组织选择 GitLab 的核心原因。

什么是CI/CD？

CI/CD 是持续集成（Continuous Integration，简称 CI）和持续部署 / 交付（Continuous Deployment/Delivery，简称 CD）的组合

为什么要有CI/CD？

没有 CI/CD，开发团队会陷入 "手动操作多、错漏多、效率低" 的麻烦，举 3 个常见场景就懂了：

改代码后，合并时发现 "一团乱"：比如 A 写了登录功能、B 改了用户信息接口，两人一周后才提交代码。合并时发现代码冲突（比如都改了同一个工具函数），得花 2 小时逐行核对；更糟的是，合并后才发现 B 用的 Node 版本比 A 高，本地能跑的代码，拉到一起就报错 ------ 这些问题，CI 会在每次提交时自动查冲突、验环境，早发现早解决。
测试漏查，bug 跑线上：开发完支付功能，手动测了 "正常付款" 就上线了。结果用户反馈 "用信用卡付款会白屏"------ 原来没测信用卡场景。有 CI 的话，会自动跑所有测试用例（包括信用卡、余额等场景），没测过的话根本不让上线。
手动部署时，手滑搞崩服务：上线新功能时，运维手动登录服务器输命令，不小心把 "测试服务器地址" 输成 "生产服务器"，直接把生产环境的代码删了 ------ 服务挂了 1 小时。有 CD 的话，会自动按配置部署，不用手动输命令，还会先备份旧版本，错了能秒回滚。

但是有了CI.CD之后就能有效的解决上面的问题：

更早发现问题：代码提交后立即触发测试，能快速定位 "语法错误""逻辑漏洞""依赖冲突"，避免问题隐藏到上线前才暴露；
减少人工成本：无需手动执行 "编译、测试、上传服务器" 等重复操作，开发者专注于写代码；
环境一致性：通过 Docker 等工具统一执行环境，避免 "本地能跑、线上报错"（如本地 Node.js 16，线上 Node.js 14 导致的兼容问题）；
加速迭代节奏：从 "代码写完→上线" 的周期从几天缩短到几小时，甚至几分钟，快速响应业务需求。

而在gitlab中，CI/CD的实现紧密依赖.gitlab-ci.yml配置文件

开发者提交代码到 GitLab 仓库（如 develop 分支）；
GitLab 检测到提交，读取 .gitlab-ci.yml 配置，启动流水线；
CI 阶段：
- 执行 lint：用 ESLint 检查代码规范；
- 执行 test：用 Jest 跑单元测试；
- 执行 build：用 npm run build 打包生成 dist 目录；
CD 阶段：
- 若 CI 全部通过，自动将 dist 部署到 开发环境（供测试人员测试）；
- 若代码合并到 main 分支（生产分支），CI 通过后，人工确认后部署到生产环境（持续交付），或直接自动部署（持续部署）；
全程日志实时显示在 GitLab 界面，失败时通过邮件 / 企业微信通知相关人员。

.gitlab-ci.yml是什么？

在 GitLab 中，.gitlab-ci.yml 是定义 CI/CD（持续集成 / 持续部署）流水线的核心配置文件，通过它可以自动化实现代码的构建、测试、部署等流程。它基于 YAML 格式，配置了 "阶段（stages）" 和 "任务（jobs）"。

以下是一个前端项目（如 React/Vue）的 .gitlab-ci.yml 示例，包含构建、测试、部署三个阶段：

yaml 复制代码

# 定义流水线的阶段（顺序执行：build → test → deploy）
stages:
    - build       # 构建阶段：编译代码、打包
    - test        # 测试阶段：执行单元测试、Lint检查
    - deploy      # 部署阶段：部署到测试/生产环境

# 构建阶段的任务
build_job:
    stage: build                  # 绑定到 build 阶段
    image: node:16                # 使用 Node.js 16 镜像作为运行环境
    script:                       # 执行的命令（构建步骤）
    - npm install               # 安装依赖
    - npm run build             # 执行打包（如 React 的 build 脚本）
    artifacts:                    # 保存构建产物（供后续阶段使用）
      paths:
        - dist/                   # 打包后的目录（如 dist）
    expire_in: 1 day            # 产物保留 1 天

# 测试阶段的任务
test_job:
    stage: test                   # 绑定到 test 阶段
    image: node:16
    script:
    - npm install
    - npm run lint              # 代码风格检查（如 ESLint）
    - npm run test              # 执行单元测试（如 Jest）
   dependencies:                 # 依赖 build 阶段的产物（可选）
    - build_job

# 部署到测试环境的任务
deploy_staging:
    stage: deploy
    image: alpine:latest          # 轻量 Linux 镜像（用于执行部署命令）
    script:
      - apk add --no-cache rsync  # 安装文件同步工具
    - rsync -avz dist/ user@staging-server:/var/www/html/  # 同步到测试服务器
    only:                         # 仅在 develop 分支触发
    - develop

# 部署到生产环境的任务
deploy_production:
    stage: deploy
    image: alpine:latest
    script:
    - apk add --no-cache rsync
    - rsync -avz dist/ user@prod-server:/var/www/html/      # 同步到生产服务器
    only:                         # 仅在 main/master 分支触发
    - main
    when: manual                  # 手动触发（避免自动部署到生产）

关键配置解析

stages ：定义流水线的执行顺序，例如 build → test → deploy。如果某个阶段的所有任务失败，后续阶段会被跳过。
任务配置（如 build_job） ：
- stage：指定任务所属的阶段。
- image：指定执行任务的 Docker 镜像（如 node:16 用于前端构建，python:3.9 用于 Python 项目）。
- script：核心配置，定义任务执行的命令（如安装依赖、编译、测试命令）。
- artifacts：保存任务生成的文件（如打包后的 dist 目录），供后续阶段（如 deploy）使用。
- dependencies：声明依赖的前置任务（仅下载指定任务的 artifacts，优化性能）。
- only/except：控制任务在哪些分支 / 事件（如合并请求）下触发（only: [main] 表示仅在 main 分支执行）。
- when: manual：设置为手动触发（适合生产环境部署，避免误操作）。

流水线

有了上面的配置文件之后，我们需要了解一个叫做"流水线的概念"，它是一个流程：

GitLab 检测到代码变更，读取 .gitlab-ci.yml 解析流水线配置。
分配 GitLab Runner 执行任务（按 stages 顺序，同一阶段任务并行）。
每个任务在独立的容器中执行（基于 image 配置），确保环境一致性。
执行结果实时显示在 GitLab 项目的 "CI/CD → 流水线" 页面，失败时会通知开发者（如邮件、Slack）。

触发时机：默认情况下，当代码推送到 GitLab 仓库（或创建合并请求）时，会自动触发流水线。

打个比方，你是团队项目中的前端开发者，今天下午你开发完了登录功能，此时你会执行 git add . → git commit -m "完成登录功能" → git push origin develop。

这个时候，GitLab 检测到 develop 分支有新提交，自动在仓库根目录寻找 .gitlab-ci.yml，按配置启动流水线，从而进行我们上面提到的这个流程！

什么是runner？

在 GitLab CI/CD 中，Runner 是实际执行 .gitlab-ci.yml 中定义的任务的 "工作进程" ，相当于自动化流程的 "执行者"。

简单说，.gitlab-ci.yml 是 "指令清单"（定义要做什么），而 Runner 是 "工人"（负责按清单干活）。

Runner 通常运行在独立的服务器、容器或虚拟机中，它会实时向 GitLab 汇报任务执行状态（成功 / 失败）、输出日志等，让开发者在 GitLab 界面上能直观看到实时查看流水线进度。

总结

作为刚入职两天的实习生，我对 GitLab 的理解还比较基础，但这段时间的体验让我明白：GitLab 不是 "难用的工具"，而是 "帮你高效协作的助手"。

对新手来说，不用追求一次性掌握所有功能：先记住 "基于 Git、企业级、协作导向" 这三个核心，学会 "拉代码、建分支、提 MR" 这几个基础操作，就能满足初期工作需求。后续再慢慢探索工单、CI/CD 等功能，就能越来越熟练。

最后希望这篇文章能帮到和我一样刚接触 GitLab 的实习生或准职场人，祝大家都能快速上手，顺利开启实习或工作之旅！