📘 使用 GitLab Fork 项目协作流程说明文档

本文档适用于新员工或协作成员,使用 GitLab Fork 项目开发与主项目协作。

📌 为什么采用 Fork 协作模式?

在 GitLab 中,我们推荐新员工或外部协作成员使用 Fork 模式 进行开发协作,原因如下:

✅ 1. 权限隔离,保障主项目安全

Fork 后你拥有自己独立的项目副本,不会直接影响主项目代码
避免误操作导致主项目不可用,是多人协作中非常重要的保障。


✅ 2. 更清晰的审阅流程

通过 Fork 创建的 Merge Request(合并请求)来自于外部项目分支,能在 GitLab 中清晰地展示:

  • 哪位成员发起了 MR;
  • 改动来源是哪一个 Fork;
  • 审核人是谁;
  • 审核和合并历史;

更有利于团队管理和代码质量控制。


✅ 3. 支持更灵活的开发节奏

Fork 后的开发者可以:

  • 独立维护自己的分支;
  • 根据需要创建多个功能分支(如 feature/xxx);
  • 在本地反复提交并测试,无需提前同步主项目变更

这为试验性开发、临时功能、敏捷团队提供了良好支持。


✅ 4. 避免权限管理复杂化

对于新员工、外包开发或临时协作者,Fork 模式不需要给予主项目的 push 权限,只需 MR 审核通过即可合并。
这样能有效控制权限风险、减少权限管理成本。


✅ 5. GitLab 对 Fork 工作流原生支持良好

  • GitLab 提供一键 Fork 功能;
  • MR 可以自动识别 Fork 项目;
  • 提交后系统会自动提示 “Create merge request”;
  • 代码审查、审批流、CI 等与主项目一样使用,无学习门槛差异

✅ 总结一句话

使用 Fork 协作,是一种 高安全性、强流程可控、低权限风险 的代码协作方式,尤其适合新员工、实习生、外包或其他没有主项目直接写权限的开发者。


具体流程

🧭 一、Fork 主项目

  1. 登录 GitLab;
  2. 打开主项目页面(如 https://gitlab.aukeyit.com/westernpost/project);
  3. 点击 派生(Fork)
  4. 选择个人命名空间进行 派生(Fork)
  5. 派生(Fork) 完成后将拥有自己的项目副本。

💻 二、克隆 Fork 项目到本地

git clone https://gitlab.aukeyit.com/your-namespace/project.git
cd project

🔗 三、配置主项目为上游 remote(upstream)

git remote add upstream https://gitlab.com/主项目组/项目名.git
git remote -v  # 验证配置成功

🌱 四、拉取并选择主项目相同迭代分支进行开发

git fetch upstream
# 修改代码
git add .
git commit -m "feat: 实现 xxx 功能"
git push origin xxx

📬 五、发起 Merge Request(MR)

  1. 推送后访问 GitLab;

  2. 点击「合并请求」;

  3. 设置目标项目为主项目,目标分支为功能对应迭代分支 例如 develop

  4. 填写 MR 标题和描述,建议格式:

    ## 描述
    - 实现功能:xxx
    - 修改文件:xxx.java, xxx.js
    
    ## 测试
    - [x] 单元测试通过
    - [x] 页面功能验证通过
    
    ## 审核人
    @zhangsan @lisi

  5. 提交后等待代码审核。


🔄 六、同步主项目代码(避免冲突)

定期或合并前同步主项目代码:

git fetch upstream
git checkout develop
git merge upstream/develop
git push origin develop

如果你的开发分支基于其他分支如 main,也需要同步更新:

git checkout feature/xxx
git merge --no-ff main

解决冲突后提交:

git add .
git commit
git push -f origin feature/xxx

✅ 七、响应审核意见并持续更新 MR

  • 若有修改建议,继续在本地修改后提交;
  • 无需重新建 MR,GitLab 会自动更新;
  • 修改完成后 @ 审核人重新确认。

🔐 九、注意事项

  • ❗ 请勿直接修改 master 分支;
  • ✅ 每个功能使用提交与主项目相同分支;
  • ✅ 提交前请做好自测,确保 CI 通过;
  • ✅ MR 描述需完整清晰,便于审核;
  • 🚫 请勿合并未经审核的 MR;

📌 示例远程配置(命令回顾)

# Fork 仓库的 remote
origin    https://gitlab.com/you/project.git

# 主项目仓库的 remote(upstream)
upstream  https://gitlab.com/group/project.git