如何使用GitLab进行版本控制

使用 GitLab 进行版本控制的实操指南

版本控制是现代软件开发的基石，而 GitLab 作为一个集成了代码托管、CI/CD 和项目管理的平台，早已成为许多团队的核心工具。这篇文章不打算照本宣科地罗列命令，而是从实际工作流出发，聊一聊怎么把 GitLab 用得顺手、高效。

我们直接进入正题。

快速上手流程

对于刚接触 GitLab 的团队来说，最快的方式就是先跑通一个最基本的“创建-克隆-提交-推送”循环。

• 创建项目：登录 GitLab 后，点击 New project，选择 Create blank project。项目名称和可见性（Private/Internal/Public）根据实际需求设置就行。这一步没什么花头，但注意别把敏感代码直接设为公开就好。
• 克隆仓库：在项目首页复制 SSH 或 HTTPS 地址，然后在本地终端执行：

git clone <仓库地址>
cd <项目目录>

• 提交与推送：有了本地仓库，就可以开始干活了。标准的初始化操作：

git add .
git commit -m "Initial commit"
git push -u origin main

这里有个细节：如果你的远程默认分支是 master，记得把命令中的 main 替换成 master。很多新手在这一步会栽跟头，无非是默认分支名没对清楚。

• 拉取更新：团队成员协作时，git pull origin main 是最常用的同步命令。这个流程无论是用 GitLab 的 SaaS 版（gitlab.com）还是自托管实例，都完全通用。关键在于两点：使用项目页面提供的正确克隆地址，以及搞清楚当前项目的默认分支名。

分支管理与合并请求

分支策略是团队协作的灵魂。没有规矩的仓库，迟早会变成一团乱麻。这里给出一个被广泛验证过的命名规范：

• 主分支：main 或 master，保持稳定，所有发布都从这里出。
• 功能分支：feature/功能名，比如 feature/user-auth。
• 修复分支：fix/问题编号-描述，比如 fix/123-login-error。
• 紧急修复：hotfix/问题编号-描述，用于生产环境的热修复。
• 发布分支：release/版本号，比如 release/1.0.0。

典型协作流程其实很清晰：

1. 从 main 创建功能分支：git checkout -b feature/new-feature main
2. 本地开发，提交代码。
3. 推送分支到远程：git push origin feature/new-feature
4. 在 GitLab 上创建 Merge Request（MR），指定源分支（你的功能分支）和目标分支（比如 main）。
5. 团队成员在 MR 中进行代码审查、讨论、提出问题。
6. 审核通过后，合并到目标分支。合并后，建议及时删除远程功能分支，保持仓库整洁。

需要警惕的是：main 或 master 必须设为受保护分支。只有通过 MR 才能合并，并且可以配置审批规则、状态检查等。这么做的目的很明确——保障主干线的稳定，不让任何未经 review 的代码直接闯入。

合并策略可以根据团队习惯选择：用 --ff-only 保持线性历史，还是用 --no-ff 保留合并节点？没有绝对的对错，但前提是大家达成共识。这些规范一旦落地，协作效率和代码质量都会有明显提升。

标签与版本发布

标签是用来标记里程碑版本的。当你的代码在 main 上稳定运行后，打一个标签就是“正式发版”的起点。

• 创建标签：

git tag -a v1.0.0 -m "Release v1.0.0"
git push origin v1.0.0

• 查看与切换标签：

git tag -l
git checkout v1.0.0

这里必须强调一个原则：回滚时优先使用 git revert。它会在当前提交的基础上创建一个“撤销提交”，而不是直接抹掉历史。直接改历史（比如 git reset --hard 后强推）在协作环境下简直是灾难，尤其是别人已经基于后续提交做了开发。如果只是想回到某个状态，也可以检出那个标签的提交——但请注意，这会导致“分离 HEAD”的状态，不要在它上面直接继续开发。

发布流程的常见做法是：在 main 稳定后打 Tag，然后配合 CI/CD 自动部署到对应环境。同时，在 MR 或 GitLab 的 Release 说明中记录该版本的变更要点。这样一来，每个版本都可追溯，一旦线上出问题，回滚到上一个标签也只是一条命令的事。

CI/CD 自动化

版本控制和自动化是天生一对。在项目根目录创建 .gitlab-ci.yml 文件，就可以定义构建、测试、部署等阶段。下面是一个最简化的示例：

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - echo "Building…"
    - ./gradlew build

test_job:
  stage: test
  script:
    - echo "Running tests…"
    - ./gradlew test

deploy_job:
  stage: deploy
  script:
    - echo "Deploying to $CI_ENVIRONMENT_NAME…"
  environment: production

每次 push 或 MR 的创建都会自动触发流水线。前提是已经正确注册并运行了 GitLab Runner。需要根据不同环境配置变量（比如数据库密码、API Key）和保护规则，这些都可以在 GitLab 的项目设置里搞定。把构建、测试、部署都纳入版本控制的闭环，人工失误率会大幅降低，交付速度也会显著提升。

自托管 GitLab 与日常维护

有些团队对数据安全和合规有更高要求，会选择自托管 GitLab。安装过程其实已经被简化得很友好了。

• 安装与启动（Ubuntu/Debian 示例）：

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
sudo EXTERNAL_URL="http://your-server-ip" apt-get install gitlab-ce
sudo gitlab-ctl reconfigure

CentOS/RHEL 版本只是包管理器和安装命令不同，思路是一样的。

• 配置要点：主要配置文件在 /etc/gitlab/gitlab.rb，需要设置 external_url，并根据实际需求配置 SMTP（用于邮件通知）、防火墙和端口（常见的是 80、443、22）。
• 备份与恢复：定期执行 gitlab-rake gitlab:backup:create。备份文件和配置文件要妥善保存，一旦服务器挂了，这可是救命稻草。
• 安全建议：启用 HTTPS/SSL，严格限制管理员访问权限，定期升级 GitLab 版本以修补安全漏洞。

自托管意味着更多的控制权，同时也意味着更多的维护责任。这些步骤覆盖了关键环节，适合那些对代码和合规性有更高要求的团队。