协作基础

这一课你将能做到

1. 解释 Fork 与 Clone 的本质区别，并画出完整协作链路
2. 配置 upstream 远程，同步上游最新代码到自己的 Fork
3. 走通「Fork → 改代码 → 发 PR → 被合并」的最小协作流程

为什么要学

开源世界的协作方式很特别：你没有权限直接往别人仓库 push。想给 React、Spring、Vue 修 bug，得先 Fork（复制一份到自己账号），改完发 Pull Request（请求对方拉取你的改动）。这套「Fork + PR」模型是开源世界的通用语言，也是很多公司内部 Git Flow 的变体。

理解这一课，你才真正理解了「分布式协作」——为什么 Git 叫分布式不只是技术架构，更是协作模式的去中心化。

先建立图像

Fork 协作模型的完整链路：

原作者账号                          你的账号
┌────────────────┐                ┌────────────────┐
│ upstream       │    Fork        │ origin (你的)   │
│ (官方仓库，你只读)│ ────────────> │ (你的副本，可写) │
└────────────────┘                └────────────────┘
        ▲                                │
        │      Pull Request              │ push
        │      （请求合并）                ▼
        │                         ┌────────────────┐
        └─────────────────────────│ 你本地的 clone  │
              审查通过后被合并      │ (工作区+本地仓库)│
                                  └────────────────┘

三个角色要分清：

• upstream：官方/原始仓库，你只读
• origin：你 Fork 后的副本，你可写
• 本地 clone：从 origin 拉下来的，你实际改代码的地方

跟着做

步骤 1：Fork 一个仓库

在 GitHub 上打开任意开源项目（比如 octocat/Spoon-Knife 这个官方教学仓库），点右上角 Fork 按钮。几秒钟后，你的账号下会多出一份 你的用户名/Spoon-Knife。

步骤 2：Clone 你的 Fork

git clone git@github.com:你的用户名/Spoon-Knife.git
cd Spoon-Knife
git remote -v
# origin  git@github.com:你的用户名/Spoon-Knife.git (fetch)
# origin  git@github.com:你的用户名/Spoon-Knife.git (push)

注意 clone 下来默认只有 origin（你的 Fork），没有 upstream。

步骤 3：添加 upstream 远程

git remote add upstream git@github.com:octocat/Spoon-Knife.git
git remote -v
# origin    git@github.com:你的用户名/Spoon-Knife.git (fetch)
# origin    git@github.com:你的用户名/Spoon-Knife.git (push)
# upstream  git@github.com:octocat/Spoon-Knife.git (fetch)
# upstream  git@github.com:octocat/Spoon-Knife.git (push)

这样你就能随时同步官方仓库的最新代码。

步骤 4：同步上游最新代码

假设官方仓库在你 Fork 后又更新了，你要同步：

git fetch upstream                  # 下载官方最新
git switch main
git merge upstream/main             # 合并进自己的 main
git push origin main                # 推回自己的 Fork

或者用 GitHub 网页上的 Sync fork 按钮一键同步（更直观）。

步骤 5：在功能分支上开发

绝不要直接在 main 上改：

git switch -c feature/add-emoji
echo "🍴" >> README.md
git add . && git commit -m "docs: 在 README 加个叉子表情"
git push -u origin feature/add-emoji

步骤 6：发起 Pull Request

push 成功后，打开你 Fork 的 GitHub 页面，会看到一个黄色提示条「Compare & pull request」，点它：

1. 确认 base 是 octocat/Spoon-Knife:main，compare 是 你的:feature/add-emoji
2. 填写标题和描述（说清楚你改了什么、为什么）
3. 点 Create pull request

接下来就等仓库维护者审查、评论、合并。整个过程你不需要对方仓库的写权限。

讲清楚要点

1. Fork 是 GitHub 层面的概念，不是 Git 命令：它是「在服务端复制一份仓库到你账号下」。复制完成后，你和原仓库就是两个独立仓库，只是 GitHub 记得你们的「血缘」关系。
2. origin vs upstream 是约定俗成：origin 指向你自己的 Fork，upstream 指向官方仓库。这只是命名习惯，但全世界都这么叫。
3. PR 是「请求对方拉取」：Pull Request 直译就是「拉取请求」——你请求维护者把你 Fork 里的改动拉（pull）到官方仓库。
4. 为什么不在原仓库直接开分支？：开源项目你不一定有权限。Fork 模型让任何人都能贡献，无需授权。
5. 同步上游是常态：长期参与一个开源项目，要定期 fetch upstream 合并，否则你的 Fork 会越来越落后。

你可能会懵的地方

• Fork 和 Clone 到底啥区别？ Fork 是「服务端复制」，发生在 GitHub 网站，结果是你账号下多了一个仓库；Clone 是「客户端下载」，发生在终端，结果是你电脑上多了一份代码。先 Fork（网站），再 Clone（终端）。

• 我能直接 clone 官方仓库改代码吗？ 能 clone、能本地改，但 push 会被拒（你没写权限）。所以必须 Fork 出自己可写的副本。

• upstream 能 push 吗？ 不能（没权限）。它的作用只有 fetch，拉取官方最新代码。

• PR 合并后我的 Fork 怎么办？ 功能分支可以删掉，main 分支下次同步上游时自动跟上。Fork 仓库本身可以保留，方便下次继续贡献。

• 公司内部项目也用 Fork 吗？ 不一定。很多公司用「共享仓库模型」：所有人都有权限，直接在主仓库开 feature 分支、发 PR，不用 Fork。Fork 主要是开源/外部贡献场景。

错法对照

错法	问题	正解
在 main 上直接改完发 PR	下次同步上游会冲突	永远开功能分支
忘了 add upstream	无法同步官方更新	第一时间 git remote add upstream ...
从不 fetch upstream	半年后 PR 全是冲突	每次开工前先同步上游 main
一个 PR 塞 10 个不相关改动	维护者直接关掉	一个 PR 只做一件事
PR 描述只写「fix bug」	审查者看不懂	写清动机、方案、测试方式

卡点急救

1. PR 提示「Can't automatically merge」：上游有新提交和你的改动冲突。先 git fetch upstream && git merge upstream/main 本地解决冲突，push 后 PR 自动更新。
2. 想改 PR 里的代码：直接在原功能分支上继续 commit + push，PR 会自动带上新提交，不用重开。
3. Fork 错了想重来：在 GitHub 仓库 Settings → Danger Zone → Delete this repository 删掉 Fork，重新 Fork 即可（不影响原仓库）。

面试常问

• Fork 和 Clone 的区别？ Fork 是 GitHub 平台功能，在服务端把别人仓库复制到自己账号下（解决无写权限问题）；Clone 是 Git 命令，把远程仓库下载到本地。协作流程通常是 Fork → Clone → 改 → push 到自己 Fork → 发 PR。

• 什么是 upstream？怎么同步 Fork？ upstream 是指向原始仓库的远程别名。同步流程：git fetch upstream → git switch main → git merge upstream/main → git push origin main。GitHub 也提供 Sync fork 网页按钮。

• 公司内部为什么不一定用 Fork？ Fork 模型适合「无权限的外部贡献者」。公司内部大家都是受信成员，通常用共享仓库+功能分支模型，省去 Fork 的跳转，协作更直接。

自测三问

1. origin 和 upstream 分别指向哪？为什么需要两个远程？
2. 为什么不要在自己 Fork 的 main 分支上直接改代码？
3. 发起 PR 之后想再改一处，要重新开 PR 吗？

小结一句话

Fork 解决「没权限也想贡献」的问题，upstream 保持与官方同步，PR 是请求合并的礼貌敲门——这三件套就是开源协作的通用语言。

延伸

• GitHub 文档：Fork 仓库
• 下一课：分支工作流——把分支用出章法，学会 Git Flow 与 GitHub Flow。