GitLab Fork Workflow 实战指南：从 Fork 到 Merge，团队协作开发标准版（2026）

文章目录

• 一、核心概念（3分钟速览）
• • [什么是 Fork Workflow？](#什么是 Fork Workflow？)
  • 三个必须搞懂的概念
• [二、完整实战：从 Fork 到 Merge（10分钟上手）](#二、完整实战：从 Fork 到 Merge（10分钟上手）)
• • 阶段一：初始化（仅首次）
  • 阶段二：开始开发
  • [阶段三：发起 Merge Request](#阶段三：发起 Merge Request)
  • [阶段四：MR 合入后清理](#阶段四：MR 合入后清理)
• [三、每日开发 SOP（日常必做）](#三、每日开发 SOP（日常必做）)
• • [Commit Message 规范](#Commit Message 规范)
• 四、五个黄金原则
• 五、最常见的坑
• [六、进阶篇（Maintainer 配置 & 底层原理）](#六、进阶篇（Maintainer 配置 & 底层原理）)
• • [6.1 Maintainer 必配项](#6.1 Maintainer 必配项)
  • [6.2 Rebase vs Merge 技术选型](#6.2 Rebase vs Merge 技术选型)
  • [6.3 底层原理：origin 和 upstream 存储在哪？](#6.3 底层原理：origin 和 upstream 存储在哪？)
• 七、FAQ
• 总结
• 相关推荐

适用人群：GitLab 团队开发者 | 企业研发新人 | 开源贡献者

阅读收获：理解 Fork Workflow 的由来 | 掌握 origin/upstream 概念 | 完成从 Fork 到 Merge 的全流程 | 避开最常见的坑

---

一、核心概念（3分钟速览）

什么是 Fork Workflow？

主项目（upstream）
       │
    Fork（复制一份到你的名下）
       │
    Clone 到本地
       │
    开发 → Push 到自己的 Fork → 发起 Merge Request → 合入主项目

每位开发者拥有自己的远程仓库 ，所有代码变更通过 Merge Request（MR） 进入主项目。

三个必须搞懂的概念

                    GitLab
          ┌──────────────────────┐
          │ upstream（主仓库）     │  ← 团队共有，你只有读取权限
          └──────────▲───────────┘
                     │ Fork
                     ▼
          ┌──────────────────────┐
          │ origin（你的 Fork）    │  ← 你拥有完整权限
          └──────────▲───────────┘
                     │ git clone
                     ▼
          ┌──────────────────────┐
          │ local（本地仓库）       │  ← 你的电脑
          └──────────────────────┘

名称	含义	你能做什么
upstream	主项目仓库	fetch / pull（只读）
origin	你自己的 Fork	push / pull（读写）
local	本地代码	随意修改

查看配置：git remote -v

---

二、完整实战：从 Fork 到 Merge（10分钟上手）

场景：为登录模块增加「记住密码」功能。

---

阶段一：初始化（仅首次）

# 1. GitLab 网页点击 Fork（复制主项目到你名下）

# 2. 克隆你的 Fork 到本地
git clone git@gitlab.com:你的用户名/项目名.git
cd 项目名

# 3. 关联主仓库（upstream）
git remote add upstream git@gitlab.com:团队组名/项目名.git

# 4. 验证
git remote -v
# 应看到 origin（你的Fork）和 upstream（主项目）

---

阶段二：开始开发

# 1. 每天开始前，同步最新代码
git fetch upstream
git switch main
git rebase upstream/main
git push origin main

# 2. 创建功能分支（永远不在 main 上开发！）
git switch -c feature/remember-password

# 3. 写代码...
vim app/login.go

# 4. 提交
git add .
git commit -m "feat: 登录模块增加记住密码功能"

# 5. 推送到你的 Fork
git push origin feature/remember-password

---

阶段三：发起 Merge Request

1. GitLab 会自动提示「Create merge request」，点击进入
2. 填写信息：
   • Source ：你的用户名/项目名 / feature/remember-password
   • Target ：团队组名/项目名 / main
   • 标题 ：feat: 登录模块增加记住密码功能
   • 指定 Reviewer：选择 1-2 位同事
3. 提交，等待 CI 通过 + Code Review

---

阶段四：MR 合入后清理

# 切回 main
git switch main

# 同步最新代码
git fetch upstream && git rebase upstream/main

# 删除本地功能分支
git branch -d feature/remember-password

# 清理远程已删除分支的本地缓存
git remote prune origin

---

三、每日开发 SOP（日常必做）

每天到岗后，按此顺序执行：

# 1. 拉取主项目最新代码
git fetch upstream

# 2. 更新本地 main
git switch main
git rebase upstream/main

# 3. 同步到你的 Fork（保持 origin/main 与 upstream/main 一致）
git push origin main

# 4. 创建/切换到功能分支
git switch -c feature/今天的功能名

# 5. 开发... 提交... 推送...
git add .
git commit -m "feat: xxxx"
git push origin feature/今天的功能名

---

Commit Message 规范

类型	用途	示例
feat	新功能	feat: 增加记住密码
fix	修复 Bug	fix: 修复登录超时
docs	文档	docs: 更新API文档
refactor	重构	refactor: 优化登录逻辑
test	测试	test: 增加登录单元测试
chore	构建/工具	chore: 升级Go版本

---

四、五个黄金原则

原则	说明
① main 只同步，不开发	main 唯一作用是同步 upstream/main，开发必须在功能分支进行
② 一个 MR 一个功能	不要把登录、支付、首页塞进同一个 MR
③ MR 尽量小	推荐几十到几百行，超过 1000 行 Review 效率骤降
④ 每天同步 upstream	减少冲突，保持代码最新
⑤ 冲突用 rebase，不用 merge	git rebase upstream/main 保持线性历史，更干净

---

五、最常见的坑

坑	后果	解决方案
在 main 上开发	同步 upstream 时冲突混乱	永远在 feature 分支开发
长期不同步 upstream	rebase 时数百个冲突	每天/每周同步一次
MR 超过 3000 行	Review 困难，缺陷易遗漏	拆分为多个小 MR
使用 git push --force	可能覆盖同事的提交	用 --force-with-lease
commit message 写 fix/update	无法追溯变更目的	遵循 Conventional Commits
推送到 upstream	被拒绝（Protected Branch）	只 push 到 origin

---

六、进阶篇（Maintainer 配置 & 底层原理）

以下内容适合项目管理员或想深入理解的开发者。

6.1 Maintainer 必配项

配置	路径	作用
Protected Branches	Settings → Repository	禁止直接 Push 到 main，只能通过 MR
Approval Rules	Settings → Merge requests	至少 1-2 人审批才能合并
Pipelines must succeed	Settings → Merge requests	CI 不通过不能合并
Delete source branch	Settings → Merge requests	合并后自动删除源分支
CODEOWNERS	.gitlab/CODEOWNERS	自动指派模块负责人评审

CODEOWNERS 示例：

app/login/   @zhangsan @lisi
app/payment/ @wangwu
*.go         @team-go

---

6.2 Rebase vs Merge 技术选型

方式	命令	结果	适用场景
Rebase（推荐）	git rebase upstream/main	线性历史，无合并提交	个人功能分支
Merge	git merge upstream/main	产生合并提交，保留分支历史	公共/长期维护分支

为什么推荐 Rebase？ 历史干净线性，评审人无需区分「你的提交」和「合并进来的提交」。

---

6.3 底层原理：origin 和 upstream 存储在哪？

git remote -v 的信息存储在 .git/config 中：

[remote "origin"]
    url = git@gitlab.com:你的用户名/项目名.git
[remote "upstream"]
    url = git@gitlab.com:团队组名/项目名.git

origin 和 upstream 是两个独立的远程仓库，没有自动同步关系 。你需要手动执行 git fetch upstream 拉取主项目更新，再 git push origin 推送到自己的 Fork。

---

七、FAQ

Q1：我 push 到 origin 后，upstream 怎么看不到我的代码？

A：正常。你需要发起 MR，将 origin/feature 合入 upstream/main。

---

Q2：MR 冲突了，用 rebase 还是 merge？

A：个人功能分支用 rebase：git rebase upstream/main。公共分支用 merge。

---

Q3：主项目删了文件，我的 Fork 里还有，怎么处理？

A：执行 git fetch upstream && git rebase upstream/main，这些文件会自动被删除。

---

Q4：我不小心 push 到 upstream 了怎么办？

A：main 有 Protected Branch 保护，push 会被拒绝。其他分支请联系管理员处理。

---

Q5：一个 MR 能有多个 commit 吗？

A：可以。但建议每个 commit 独立可编译。若 commit 过多，可用 git rebase -i 合并。

---

总结

一句话记住 Fork Workflow：

主仓库负责稳定，Fork 负责开发；功能分支承载变更，Merge Request 承担评审。

当团队遵循这一流程时，代码变更清晰可追溯，协作风险大幅降低。这也是开源社区和企业研发团队最成熟的协作模式。

---

相关推荐

Mac 终端命令行完全指南（2026 收藏版）

Git 命令行完全指南（2026 收藏版）