核心三步是：先执行git remote add upstream 原仓库https地址添加上游远程，再git fetch upstream拉取更新，最后git merge --ff-only upstream/main或git rebase upstream/main安全合并；跳过第一步则后续操作均无效。
直接同步 fork 仓库和上游（original）仓库，核心就三步：加 upstream 远程、fetch、再 merge 或 rebase。跳过加 upstream 这步，后面所有操作都会报错或无效。
怎么加 upstream 远程源才不会出错
很多人卡在第一步，不是 URL 写错，就是没确认当前分支。加 upstream 只需一次，但必须在正确的本地仓库目录下执行：
- 先用
git remote -v确认是否已有upstream；如果看到remote upstream already exists提示，跳过这步 - URL 一定要用原始仓库的 HTTPS 地址（比如
https://github.com/vuejs/core），别复制自己 fork 的地址 - 命令是
git remote add upstream https://github.com/original-owner/repo.git，不是git remote add origin ... - 加完立刻跑
git remote -v，应看到两行upstream（fetch 和 push），且域名指向原始作者，不是你自己的用户名
git fetch upstream 之后为什么 merge 不了
fetch 只下载对象，不创建本地分支引用。所以 git merge upstream/main 失败，往往是因为本地还没见过 upstream/main 这个引用——Git 不知道它存在。
- 运行
git fetch upstream后，立刻执行git ls-remote --heads upstream，能列出所有上游分支名，确认main或master是否在其中 - 如果上游用的是
dev作主干，就得用upstream/dev，不能硬写main - 常见错误是
git merge upstream/main报fatal: refusing to merge unrelated histories：这是 fork 后首次合并的正常现象，加--allow-unrelated-histories即可，只用一次
merge 还是 rebase？选错会影响协作
区别不在“好不好”，而在“推没推过”。一旦你把本地分支 push 到自己的 origin，再 rebase 就得强推，会破坏他人已拉取的历史。
- 本地还没
git push origin main过：用git rebase upstream/main更清爽，提交线性，无合并记录 - 已经
push过，且别人可能基于你的分支工作：坚持用git merge --ff-only upstream/main，失败时手动处理 diverge，不强推 - 想省事又怕冲突，就用
git merge upstream/main（不加--ff-only），但要注意它会生成一个合并提交，时间线变胖
同步完要不要 push origin
要，但只推你真正维护的分支。别把实验性分支、临时调试分支一起推上去。
- 同步完
main后，执行git push origin main，让 GitHub/GitCode 上的 fork 显示“up to date” - 如果你维护的是
dev分支，并希望它也跟上游main保持一致，得先git checkout dev，再git merge upstream/main，最后git push origin dev - 别用
git push --all origin全量推送：可能把你不打算公开的分支、含敏感信息的 commit 也发出去
最易被忽略的一点：每次同步前，先 git status 看一眼有没有未提交的修改。如果有，要么先 commit 或 stash，否则 merge 很可能中途卡住等你解决冲突——而你根本没意识到是自己本地改了什么。
