同步 Fork 仓库需先配置 upstream 远程，再 fetch 才可见 upstream/main；同步上游变更应据分支共享情况选 merge（已共享）或 rebase（仅私有），且 PR 冲突必须本地解决，GitHub Web 仅支持简单文本冲突。
同步 Fork 仓库的分支不是“一键更新”操作，它本质是本地 Git 的远程跟踪 + 合并/变基流程；Pull Request 冲突必须在本地解决，GitHub Web 界面只支持简单文本冲突，复杂逻辑冲突会直接禁用“解决冲突”按钮。
git fetch upstream 之后为什么看不到 upstream/main？
你漏掉了 upstream 远程的配置。GitHub 上 Fork 后，你的本地仓库默认只有 origin（指向你自己的 fork），没有指向原项目（即 upstream）的远程。不加这一步，git fetch upstream 会报错：fatal: 'upstream' does not appear to be a git repository。
实操建议：
- 先运行
git remote add upstream https://github.com/ORIGINAL-OWNER/ORIGINAL-REPO.git（URL 必须是原项目的 HTTPS 地址，不是你自己的 fork） - 确认添加成功：运行
git remote -v，应看到两行 ——origin指向你的 fork，upstream指向原项目 -
upstream名字可自定义（比如叫parent），但后续所有命令中的远程名必须保持一致 - 首次添加后，必须执行
git fetch upstream才能拉取 upstream 的分支信息；之后再运行git branch -r就能看到upstream/main等远程分支了
merge 和 rebase 哪个更适合同步上游变更？
取决于你是否已将本地分支推送到 GitHub 并被他人基于它继续开发。如果该分支只属于你、尚未共享，用 git rebase upstream/main 更干净；如果已推送且别人可能基于它工作，就只能用 git merge upstream/main，否则会重写公共历史，引发协作灾难。
常见错误现象：
- 执行
git rebase upstream/main后，git push origin main失败，提示non-fast-forward update - 同事拉取你的分支后发现 commit hash 全变了，本地历史和远程对不上
实操建议：
- 同步前先问一句：“这个分支有没有被别人 clone 或基于它开新功能？”——有则 merge，无则 rebase
- rebase 后若需强制推送，用
git push --force-with-lease origin main（比--force安全，不会覆盖他人新提交） - merge 会产生一个合并提交，虽略显冗余，但历史可追溯、协作安全
GitHub Web 界面提示 “Resolve conflicts”，但点进去只有部分文件可编辑
这是 GitHub 的限制：它只允许在线编辑纯文本文件（如 .md、.js、.py）中由 >>>>>> 标记的简单行级冲突；一旦涉及二进制文件（.png、.pdf）、Git 子模块、或冲突块内含语法错误/缩进混乱/多处嵌套修改，按钮就会灰掉，显示 “This merge cannot be resolved on GitHub”。
实操建议：
- 看到 “Resolve conflicts” 按钮不可用，别硬试，立刻切到本地
- 本地执行
git pull origin main（确保你当前分支最新），再运行git merge upstream/main，Git 会明确告诉你哪些文件冲突，并停在中间状态 - 用 VS Code 打开，左侧源代码管理面板会高亮冲突文件，点击即可跳转到冲突块，支持点击“Accept Current Change”、“Accept Incoming Change”或手动编辑
- 解决完所有冲突后，必须
git add .标记为已解决，再git commit（message 可写resolve merge conflicts with upstream/main），最后git push
同步后 PR 仍显示 conflict，但本地 git status 是 clean
这是因为 GitHub 的 PR 冲突检测是基于你 PR 的 base 分支（比如 main）与 head 分支（比如 your-fork:feature-x）的**当前远程快照**比对结果，不是看你本地有没有 commit。即使你本地已 merge 并 push，只要 base 分支（原项目 main）在你 push 后又有了新提交，PR 就会再次标红。
容易被忽略的关键点：
- 同步上游 ≠ 一劳永逸。原项目每新增一次提交，你的 PR 就可能重新进入 conflict 状态
- 不要依赖 “Sync fork” 按钮（Web UI）来修复 PR 冲突——它只更新你 fork 的 default 分支（如 main），不更新你 PR 所在的功能分支
- 正确做法：切换到你的 PR 分支（如
git checkout feature-x），再git rebase upstream/main（或git merge upstream/main），解决冲突，git push --force-with-lease origin feature-x - CI 检查失败也可能是这个原因：你 rebased 后没 force push，远程分支还是旧的、带冲突的历史
