为什么需要它
心智模型
你想用别人的代码，但又没有权限直接改动它，怎么办？复制仓库（Fork）就像复印了一本书：书是原作者的，复印件是你能随便写字的。你用复印件做自己的事，改好了再寄回一本给原作者，等对方决定要不要收下。它解决了「我没权限改你的代码，但我又想参与」这个核心问题。
历史背景 · 它为什么诞生诞生于 2008
诞生开源协作中外部贡献者无权写主仓库，需一份自己的副本再合并回上游。GitHub上线即支持fork并让它极易操作（2008年12月官方博客已介绍同步功能），2011年推出"Fork and edit file"按钮，让贡献者无需写权限即可在网页上改文件并自动提交到fork。
演进Fork从"玩源码副本"演化为正式贡献入口：2011年起点击编辑自动fork+跳转PR页，配合Fork+PR协作模型成为开源标准；2024年起支持移动端fork公共仓库，形成"任何人可独立工作、低摩擦贡献"的模型。
历史教训
降低外部贡献的门槛（一个按钮完成fork+编辑+PR）能指数级扩大贡献者池；"让没权限的人也能安全参与"是开源繁荣的关键机制，摩擦即壁垒。
功能介绍
复制仓库（Fork）是 GitHub 上的一键操作，它会给你生成一份「你自己的副本」仓库。官方定义是：一份你拥有的仓库副本（a copy of a repository that you own），它与原仓库之间保持着连接，原仓库被称为上游仓库（upstream repository）。Fork 出来的副本和上游共享全部提交历史，所以你随时能对照原仓库的进度。关键机制是：你不需要上游的写权限（write access），就能在副本里自由修改。当你在副本上做出改进后，可以用拉取请求（Pull Request）把改动提议回传给上游，由上游维护者决定是否合并。这就像「开源世界里的标准化借书流程」。此外，Fork 副本需要定期从上游拉取更新（fetch upstream），保持自己不落后于原仓库的进度。
核心术语
复制仓库（Fork）上游仓库（Upstream Repository）写权限（Write Access）拉取请求（Pull Request）同步（Sync）
适用场景
- 当你想参与一个自己没写权限的开源项目时，用 Fork 创建自己的副本。
- 当你想在别人的代码基础上做自己的实验或定制功能时，先 Fork 再改动。
- 当你想用某个现成模板启动新项目时，Fork 一份作为起点。
- 当项目团队要求「先 Fork 再提 PR」的协作流程时，按规范操作。
怎么操作（网页 vs 命令行 双轨）
🖱️ 网页操作 (GitHub.com)
- 打开目标仓库页面，点击右上角的 Fork 按钮。
- 在弹出页面选择归属（自己的账号或所属组织），点击 Create fork 确认。
- 修改完代码后，回到你的副本仓库点击 Contribute → Open pull request 提议合并。
- 日常保持同步：进入副本仓库，点击 Sync fork → Fetch upstream 拉取上游更新。
⌨️ 命令行 (进阶)
git remote add upstream https://github.com/原作者/原仓库.gitgit fetch upstreamgit checkout main; git merge upstream/maingit push origin main
新手建议先从网页操作入手，熟悉概念后再尝试命令行。命令行是真实开发中更常用的方式。
与其他功能的关系
| 关系（前置依赖 / 包含从属 / 概念升级 / 流程承接） | 说明 |
|---|---|
| 概念升级远程仓库（Remote Repository） | fork 是他人远程仓库的独立副本，先理解远程仓库概念 |
| 流程承接拉取请求（Pull Request） | 无写权限时通过 fork 后提 PR 回流变更 |
官方文档
小结
SUMMARY
记住：Fork 是「复印一份自己说了算的副本」，它与上游共享历史，用 Pull Request 回流变更。用 branch 还是用 fork？有写权限、改动小，用 branch 就够了；没写权限或要独立开发，就用 fork。下一步学 Pull Request，把副本里的改动正式提回去。