GitLab企业开发工作流实战：SSH配置、分支开发与Merge Request指南

写给即将进入企业开发的工程师

适用系统：

• ✓ macOS Intel / Apple Silicon

• ✓ Windows（WSL2）

适用场景：

• ✓ GitLab SaaS（gitlab.com）

• ✓ 企业自建GitLab

• ✓ GitLab CE / EE

本文最终目标：

从零开始，在GitLab上创建一个私有项目，配置SSH密钥完成首次代码提交，并模拟企业级开发流程：创建功能分支 → 开发 → 发起Merge Request → Code Review → 合并到main分支。

如果你完成本文，你将掌握企业中使用GitLab的标准工作流。

一、创建GitLab私有项目

步骤1：登录GitLab并创建项目

步骤2：填写项目信息

• Project name：输入你的项目名称，例如 Aeternus

• Project URL：这里需要注意！GitLab会让你选择项目的所属位置：

  • 选你的用户名 → 个人项目

  • 选一个Group → 团队项目（企业里通常选这个）

• Visibility Level：选 Private（私有，只有你和项目成员能看）

• 不要勾选​ Initialize repository with a README（因为我们本地已有项目）

点击 Create project。

为什么要注意Group？​ 企业里项目通常归属于团队（Group），而不是个人。如果选错，后续迁移会比较麻烦。新人第一次创建时，建议先选个人项目熟悉流程。

创建完成后，你会看到项目首页，右上角有一个 Clone按钮，点击后选择 Clone with SSH，复制地址：

git@gitlab.com:你的用户名/Aeternus.git

先放着，后面会用到。

二、配置SSH Key

如果你已经在GitHub那篇教程中配置过SSH密钥，那么好消息是：同一套SSH密钥可以同时用于GitHub和GitLab，不需要重新生成。

步骤1：查看本地是否已有SSH密钥

打开终端，执行：

ls ~/.ssh

如果你看到 id_ed25519和 id_ed25519.pub两个文件，说明你已经生成过密钥，可以直接跳到步骤3。

如果你没有看到这两个文件，或者你想为GitLab单独生成一套密钥，继续步骤2。

步骤2：生成新的SSH密钥对

ssh-keygen -t ed25519 -C "你的GitLab注册邮箱"

交互过程和GitHub完全一样，一路回车即可。

步骤3：查看公钥内容并复制

cat ~/.ssh/id_ed25519.pub

完整复制输出的内容。

步骤4：GitLab网页端配置公钥

步骤5：测试SSH连接

ssh -T git@gitlab.com

如果看到以下提示，代表配置成功：

Welcome to GitLab, @你的用户名!

⚠️ 注意：不要因为配置GitLab就删除原来的SSH Key。

同一套SSH Key可以同时用于：

• GitHub

• GitLab

• 公司服务器

• 云服务器

只需要把公钥再添加到GitLab即可。除非你明确知道自己在做什么，否则不要删除 ~/.ssh下已有文件。

三、首次提交代码到GitLab

步骤1：进入你的项目根目录

cd /Users/edy/PycharmProjects/Aeternus

步骤2：初始化Git仓库

git init

步骤3：配置Git用户名和邮箱（如果之前没配过）

git config –global user.name "你的名字"
git config –global user.email "你的邮箱"

步骤4：创建.gitignore

如果你还没有 .gitignore文件，创建一个并写入需要忽略的规则。Python项目示例：

__pycache__/
*.py[cod]
*.so
.env
venv/
.idea/
.vscode/
*.log

步骤5：添加文件并提交

git add .
git commit -m "初始化提交：Aeternus接口自动化框架"

步骤6：关联远程仓库

git remote add origin git@gitlab.com:你的用户名/Aeternus.git

步骤7：推送代码

git branch -M main
git push -u origin main

验证是否推送成功

git remote -v # 查看远程仓库地址是否正确
git branch # 查看当前分支是否为main
git status # 查看工作区是否干净

刷新GitLab项目页面，你应该能看到代码已经出现在仓库中。

四、企业开发流程：为什么公司不允许直接往main提交代码？

如果你是自己做个人项目，直接在 main分支上开发、提交、推送，完全没问题。

但在企业里，这样做是不被允许的。

原因很简单：

• main分支是稳定版本：线上的代码、发布的版本，都基于main分支。任何人直接往main推送代码，都可能引入Bug，导致线上事故。

• 没有Code Review：直接推送意味着代码没有被其他人审查过，质量问题、安全隐患都无法被发现。

• 无法追溯：出了问题不知道是谁改的、为什么改、有没有经过测试。

很多公司的GitLab会直接保护main分支。即使你拥有项目权限，执行 git push origin main也会收到：

remote: You are not allowed to push code to protected branches.
fatal: failed to push some refs

因为公司要求：所有代码必须通过Merge Request进入main。

所以企业里普遍采用分支开发 + Merge Request的工作流：

main（稳定版本）
↑
Merge Request + Code Review
↑
feature/xxx（功能开发分支）

这个流程确保了：任何代码进入main之前，都必须经过审查和验证。

五、Merge Request完整实战

现在我们模拟一个真实场景：你需要为项目新增一个登录功能的测试用例。

步骤1：创建功能分支

git checkout main
git pull origin main
git checkout -b feature/add-login-tests

checkout -b的意思是：创建并切换到新分支。分支名 feature/add-login-tests遵循了常见的命名规范（见第七节）。

⚠️ 注意：​ 很多公司要求创建功能分支之前，必须先同步最新main。否则你基于旧代码开发，后续Merge Request时容易出现大量冲突。

步骤2：在分支上开发和提交

假设你新增了一个测试文件 test_login.py，然后：

git add test_login.py
git commit -m "feat: 新增登录功能测试用例"
git push origin feature/add-login-tests

⚠️ 注意：​ 第一次推送新分支时，可能会提示 fatal: The current branch has no upstream branch.，此时应执行 git push -u origin feature/add-login-tests建立关联，以后直接 git push即可。

步骤3：在GitLab网页端发起Merge Request

在创建MR的页面中：

• Title：填写MR标题，例如 feat: 新增登录功能测试用例

• Description：描述你做了什么、为什么做、如何验证

• Assignee：负责处理这个MR的人（通常是自己）

• Reviewer：负责审核代码的人（可以邀请团队成员）

• Labels：可选，给MR打标签，如 feature、test

点击 Create merge request。

步骤4：Code Review与合并

MR创建后，团队成员会在MR页面看到你的代码变更。他们可以：

• 逐行查看代码差异

• 在具体代码行上留下评论和建议

• 批准或拒绝MR

很多公司还会要求以下三项全部满足后，Merge按钮才会变成可点击状态：

• ✓ Reviewer通过

• ✓ CI Pipeline通过

• ✓ 冲突检查通过

当所有条件都满足后，你就可以点击 Merge按钮，将 feature/add-login-tests的代码合并到 main分支。

步骤5：合并后清理本地分支

合并完成后，切回main分支并删除本地功能分支：

git checkout main
git pull origin main
git branch -d feature/add-login-tests

⚠️ 注意：​ 很多新人会在Merge完成后继续在旧的功能分支上开发。这是一个坏习惯。功能已经合并后，正确的做法是：

git checkout main
git pull origin main
git checkout -b feature/new-task

这样可以避免把旧任务的历史改动带到新任务中。

六、企业里一天是怎么开发的？

这一章是整篇最值钱的内容。很多教程不会写，但它是你明天上班就会用到的。

早上到公司：

git checkout main
git pull origin main

拉取最新的main分支代码。

接到一个新任务：

先同步最新代码，再创建功能分支：

git checkout main
git pull origin main
git checkout -b feature/add-login-tests

开始开发：

写代码、调试、本地测试。

开发完成：

git add .
git commit -m "feat: 新增登录功能测试用例"
git push origin feature/add-login-tests

⚠️ 很多新人以为：​ git push之后代码就已经进入main了。实际上并没有。代码只是被推送到了远程功能分支 feature/add-login-tests。只有Merge Request审核通过并完成Merge之后，代码才真正进入main分支。

发起Merge Request：

在GitLab网页端创建MR，指定reviewer。

等待Code Review：

reviewer会在MR页面留下评论，可能有修改意见。

根据意见修改：

# 修改代码
git add .
git commit -m "fix: 根据review意见修改断言逻辑"
git push origin feature/add-login-tests

推送后MR会自动更新，reviewer可以看到最新改动。

MR通过，合并：

点击 Merge按钮，代码合并到main。

清理：

git checkout main
git pull origin main
git branch -d feature/add-login-tests

这就是很多互联网公司工程师每天都会重复几十次的流程。

七、分支命名规范

企业里通常有统一的分支命名规范，便于团队理解和协作。以下是最常见的规范：

前缀

用途

示例

命名建议：

• 使用英文，小写字母

• 单词之间用短横线 -分隔

• 尽量简短但表意清晰

• 避免使用中文和特殊字符

八、本地合并 vs MR合并：什么时候用什么？

很多新人会问：我能不能直接在本地合并分支，然后推送到main？

答案是：看场景。

个人项目或实验性项目

可以直接在本地合并：

git checkout main
git merge feature/xxx
git push origin main

团队项目或正式项目

必须走MR流程。

因为：

• MR提供了Code Review的机会

• MR记录了谁在什么时候合并了什么代码

• MR可以触发CI自动化检查

• MR可以在发现问题时随时关闭，不会污染main分支

一句话原则：​ 只要代码会影响他人或线上环境，就走MR。

九、你已经掌握了什么

如果你已经跟着操作完成了这篇文章，那么你已经掌握了：

✓ 创建GitLab私有项目

✓ 配置SSH Key并连接GitLab

✓ 首次提交代码到GitLab

✓ 理解企业为什么不允许直接推main

✓ 创建功能分支并发起Merge Request

✓ 完成Code Review和代码合并

✓ 了解企业工程师一天的开发流程

✓ 掌握分支命名规范

✓ 区分本地合并和MR合并的使用场景

很多人以为，会写代码就是工程师。实际上，会协作、会Review、会把代码安全地交付出去，才是真正进入工程化开发的开始。

学会发起MR、做Code Review、遵守分支规范，是从个人开发者走向团队工程师的关键一步。