TL;DR：跑 git fetch upstream && git merge upstream/main && git push origin main，fork 就同步完了。这就是”git 同步 fork 与上游”工作流的全部——从你 fork 的项目拉取改动，再推到你的副本。喜欢线性历史，就把 merge 换成 git rebase upstream/main 再 force push。如果你压根没配过 upstream remote，从下面的第 1 步开始——缺这个 remote 正是 fork”同步不动”的头号原因。其余一切——rebase、GitHub 同步按钮、推不动的分叉分支——都是这三条命令之上的细节。
同步 fork 与上游是什么意思？
fork 是你在 GitHub 上对别人仓库的副本。原仓库叫 upstream，你的副本叫 origin。GitHub 的 fork 不会自己更新——维护者合并了 pull request，你的副本还停在昨天的代码。同步 fork 就是把上游的新提交拉进你的 fork，让你的分支与项目当前状态保持一致，至少也要包含它。
这件事重要有两个原因。第一是贡献：从过期 fork 发起的每个 pull request 都带着额外噪音，维护者会要求你先更新再合并。第二是自托管或研读代码：生产环境跑着 fork、或者只是读这份代码，一个月没同步的 fork 等于缺了一个月的 bug 修复。
怎么在命令行同步 fork 与上游？
三步：声明一次 upstream，从它 fetch，然后 merge 并 push。接线是一次性的——下次只需敲第 2、3 步。
第 1 步——添加 upstream remote（每个克隆只做一次）。
# 在你本地克隆的 fork 仓库里
git remote add upstream https://github.com/ORIGINAL_OWNER/REPO.git
git remote -v # 确认：origin 指向你的 fork，upstream 指向原仓库正确 URL 在原仓库页面的绿色 Code 按钮里能找到。常见错误是两个 remote 都指着自己的 fork——这样”同步”会悄悄什么也不做，因为你 fetch 的是一个和你手里同样过期的副本。
第 2 步——fetch 并 merge 上游分支。
git checkout main
git fetch upstream
git merge upstream/main
git push origin main这就是”git sync fork with upstream 命令行”的标准答案。正常结果是 fast-forward——你 fork 上的 main 没有自己的新提交，于是直接滑到 upstream/main，不会产生 merge commit。
第 3 步——按需重复。需要记住的只有 git fetch upstream && git merge upstream/main && git push origin main。想在 merge 前看看落后多少，fetch 之后跑 git rev-list --count main..upstream/main。
同步 fork 时该 rebase 还是 merge？
两种方式最终落到 fork 里的代码一样，留下来的历史不同。每个仓库选定一种策略，然后坚持：
| 方法 | 命令 | 历史结果 | 最适合 |
|---|---|---|---|
| Merge | git merge upstream/main | 分叉分支上多出一个 merge commit | 带着进行中 PR 的功能分支——绝不改写任何东西 |
| Rebase | git rebase upstream/main | 你的提交重放到顶端，历史线性 | 保持 fork 的 main 干净；重置分叉的 fork |
| GitHub 网页 | Sync branch 按钮 / PR merge | 同 merge | 不开克隆快速跟进 |
同步的 rebase 变体：
git fetch upstream
git rebase upstream/main
git push --force-with-lease origin mainforce push 是必需的，因为 rebase 改写了提交 ID——你 fork 的远端分支不再是本地分支的后代。永远用 --force-with-lease 而非 --force：如果期间有人（或你自己的另一台机器）推送过，它会拒绝覆盖，把危险命令变成默认安全。
有一条值得纹在手腕上的规矩：分支上还挂着进行中的 PR 时，别 rebase 它，除非你清楚自己在干什么——rebase 会改提交 ID，可能让已开的 PR 与它的提交脱钩。main 用 merge 同步（或开工前 rebase），PR 分支别掺和进来。
为什么我的 fork 同步不了上游？
四个常见嫌疑，按真实终端里出现的顺序排：
- 没有
upstreamremote——git remote -v只显示origin。症状：git fetch upstream报错'upstream' does not appear to be a git repository。修复：上文第 1 步。 - fetch 了但没 merge——fetch 只更新本地仓库里的
upstream/main，不碰任何工作分支。症状：fetch 成功后git log还是旧的。修复：git merge upstream/main。 - 历史分叉——你往 fork 的
main提交过，上游也在前进。这时git pull会抱怨历史不相关，或强行制造 merge。修复（如果你想让上游赢）：git reset --hard upstream/main（会丢掉只存在于你本地 main 的提交——先看git stash list或开个分支备份；如果糟糕的 reset 已经发生，恢复方法和 git 撤销上一次提交里的一样：git reflog还记得旧的顶端）。 - rebase 后 push 被拒为 non-fast-forward——你 rebase 了，但用了普通 push。修复：
git push --force-with-lease origin main。
第五种少见情况：上游仓库被改名或删除，连第 1 步的 URL 都 404。GitHub 会重定向改名仓库，所以硬性失败通常意味着已删除或转为私有——没有东西可同步了。
能在 GitHub 网页上同步 fork 吗？
能。在你 fork 的页面上，只要分支落后了，分支下拉框旁边就会出现 Sync fork 按钮，点一下就把上游拉进来。页面下方还有一条 PR 路线：从 upstream/main 向你 fork 的 main 开一个 PR 并合并。
按钮的局限说明了什么时候该回到命令行：它只做 fast-forward 或 merge——不会 rebase，分支分叉时直接拒绝，让你丢弃提交或改用命令行。它也只同步默认分支。凡是超出简单跟进的操作，上面那三条命令才是工具。
fork 应该多久同步一次？
诚实的答案是：每次开工之前。从新鲜的 main 切分支，你开的每个 PR 就不会以”这是基于三周前的版本”开场。活跃贡献的 fork，每天或每个会话同步一次 main，只花几秒钟。只读或只拿来部署的 fork，上游发了你想要的东西再同步——订阅原仓库的 releases feed，发版即同步。同步之所以便宜，恰恰因为它常规；落后六个月的 fork 往往需要的不是 merge 而是外科手术，这正是”同步一下我的 fork”变成一下午的常见路径。
速查表
# 一次性配置
git remote add upstream https://github.com/ORIGINAL_OWNER/REPO.git
# 日常同步（merge 策略）
git fetch upstream && git merge upstream/main && git push origin main
# 日常同步（rebase 策略，线性历史）
git fetch upstream && git rebase upstream/main && git push --force-with-lease origin main
# 我落后了多少？
git fetch upstream && git rev-list --count main..upstream/main
# 分叉到无可挽回——让 main 与上游完全一致（破坏性操作）
git fetch upstream && git reset --hard upstream/main && git push --force-with-lease origin main把日常那两行练进肌肉记忆，分叉的 fork 就永远只是你在别人故事里读到的奇闻，而不是你要修的问题。如果你的 git 保洁延伸到了服务器，journalctl 速查表负责另一半——让机器的历史保持可读。
— mrsaynothing
Get the next one by email
One email per post. No spam, no algorithms.
what is this?喜欢这些文章？我的本职工作就是这样的工程。 雇用我