《如何给开源项目提第一个 PR》 里讲过 Fork 流程：Fork 到自己名下，改完提 PR。但很多人 Fork 之后就扔那儿了，过了几个月想接着改，发现上游已经更新了几十个版本，自己的 Fork 还停在当初，合代码合到怀疑人生。这篇讲讲 Fork 之后怎么跟上游保持同步。

先理解三者的关系

Fork 之后，世界上有三个仓库：

  • 上游（upstream）：原作者的仓库，是源头。
  • 你的 Fork（origin）：你名下的复制品，你改代码的地方。
  • 你的本地：clone 下来的工作区。

同步的方向永远是：上游 → 你的 Fork → 你的本地。别搞反了，你改的东西要推到自己的 Fork，再从 Fork 提 PR 给上游。

方法一：网页端点一下（最省事）

GitHub 网页端现在很贴心：如果你的 Fork 落后于上游，仓库首页会显示一行提示，类似 “This branch is X commits behind upstream”，旁边有个 Sync fork 按钮。点一下，下拉选 Update branch，搞定。

适合场景：你只是 Star 式 Fork，偶尔看看代码，或者改动很小。注意：如果你的 Fork 里有自己独有的提交，点同步之前确认不会冲突——一般情况下 GitHub 会处理 fast-forward，合不拢它会提示你。

方法二：命令行（最可靠）

经常改代码的人，建议走命令行。思路分三步：

第一步：把上游加为 remote。

git remote add upstream 原仓库地址

只需要做一次。origin 是你的 Fork，upstream 是原仓库，两个 remote 各司其职。

第二步：拉上游的更新。

git fetch upstream

这一步只是把上游的最新状态拉到本地，还没动你的代码，安全。

第三步：合并到你的分支。

git merge upstream/main

如果提示冲突，就地解决。之前讲 Git 基础时提过，merge 冲突不可怕，逐个文件处理就行。解决完 push 到你的 Fork，同步完成。

什么时候同步一次？

看使用频率：

  • 准备提 PR 之前：必须同步。不然你的 PR 基于旧代码，作者合也不是、不合也不是，大概率让你先 rebase。
  • 长期维护的 Fork：比如你 Fork 了个工具自己加功能长期用，建议每周同步一次，免得差距越拉越大，最后合不动。
  • 纯围观的 Fork：无所谓，想起来点一下网页端的 Sync fork 就行。

两个常见坑

坑一：直接在 Fork 的 main 分支上改代码。

提 PR 的正确姿势是新建分支改，main 保持干净、只用来同步上游。如果 main 被你改得面目全非，同步上游时会很痛苦。分支管理这点，Git 基础那篇里展开过。

坑二：Fork 了之后上游改名/删库。

小概率但有。上游删库你的 Fork 还在（GitHub 会保留），但同步通道就断了。这种只能认，重要项目建议定期本地备份一份。

一句话总结

Fork 不是一次性的复制，而是建立了一条跟随上游的通道。养成同步的习惯——提 PR 前必同步，长期 Fork 每周同步一次。用网页端点按钮还是命令行，看你的使用强度选。别让你的 Fork 变成与世隔绝的孤岛。