Fork 协作模型
Fork 模型把「谁有写权限」与「谁能贡献代码」分开：贡献者把仓库 Fork 到自己的命名空间开发，再向上游仓库提 PR/MR，由上游保留合并决定权。贡献者不需要上游写权限，开源项目与跨组织协作都用这一套。
基本信息
| 仓库结构 | origin 指向自己的 Fork，upstream 指向上游仓库 |
|---|---|
| 贡献路径 | 在 Fork 的分支开发，向上游提 PR/MR |
| 权限要求 | 贡献者无需上游写权限 |
| 同步方式 | git fetch upstream 后把分支 rebase 到 upstream/main |
典型使用场景
- 向开源项目提交修复或文档改进
- 跨公司协作但不愿给对方仓库写权限
- 外包与外部贡献者参与开发，权限边界要清晰
- 上游需要保留全部合并决策与发布控制权
- 贡献者需要独立空间做实验，不影响上游分支列表
常用示例
常用示例
git clone git@github.com:<你的账号>/repo.git # 先克隆自己的 Fork
cd repo
git remote add upstream https://github.com/<上游组织>/repo.git # 添加上游远端
git fetch upstream # 拉取上游最新状态
git switch -c fix/typo upstream/main # 基于上游主干开分支
git push -u origin fix/typo # 推到自己的 Fork
# 再到网页上向 upstream 提 PR，注意目标仓库别选错与同仓库分支对比
| 对比项 | Fork 模型 | 同仓库分支 |
|---|---|---|
| 写权限 | 贡献者无需 | 必须授予 |
| 隔离程度 | 独立命名空间 | 同一仓库内 |
| 典型场景 | 开源、跨组织 | 团队内部协作 |
| 评审入口 | 上游仓库的 PR/MR | 仓库内的 PR/MR |
Fork 的默认分支会随上游前进而落后：提 PR 前先 fetch upstream 并把分支 rebase 到 upstream/main，可以避免大量无意义的冲突标记。
Fork 是平台概念而不是 Git 概念：本地看到的只是两个普通远端，所谓同步上游要靠自己执行 fetch 与 rebase，平台页面上的同步按钮本质上也是替你完成这两步。
贡献完成后 Fork 可以保留也可以删除：长期贡献者通常保留，以免历史评审链接失效；只提交过一次性补丁的可以清理，删除前确认没有未合并的分支。