pr冲突源于分支历史分叉而非文件内容差异，需用git reset --hard upstream/branch强制对齐上游干净基线，再通过cherry-pick（注意-m 1和--skip）或更稳定的补丁法恢复自研代码。
为什么 git pull 显示 Already up to date 却 PR 仍有冲突
这不是代码内容冲突，而是提交历史分叉导致的基线不一致。GitHub 判定 PR 是否可合并，看的是两个分支的共同祖先（common ancestor），不是文件内容是否相同。git merge upstream 返回 Already up to date，只说明你本地分支「包含」上游所有提交，但如果你之前执行过 git merge 生成了合并提交（比如 Merge branch 'zhanma666-dev-ai-contest-2026' into dev-ai-contest-2026），那你的分支就不再是上游的线性延伸——它多了一个额外的父提交，Git 认为它和上游不再共享同一段干净历史。
如何强制对齐到上游干净基线
必须丢弃本地产生的分叉式合并提交，让本地分支完全重置为上游当前 HEAD 的快照。这一步不能用 git merge 或 git rebase，它们都会保留或重构历史，而你需要的是“物理对齐”：
-
git reset --hard upstream/dev-ai-contest-2026—— 这会清空你本地分支上所有非上游提交（包括那个分叉Merge提交） - 执行后，你本地工作区会变成纯上游状态，所有自研代码暂时消失（别慌，它们还在 reflog 或原分支引用里）
- 确保远程 upstream 已正确配置：
git remote set-url upstream https://github.com/open-vela/contest2026_201_chaojizhuzhuxia.git，再git fetch upstream
找回自研代码的两种方式：cherry-pick vs 补丁法
重置后要恢复自己的改动，cherry-pick 看似直接，但极易失败——只要你的提交是合并提交（merge commit），git cherry-pick 就会报错，除非加 -m 1 指定主父提交；而且如果某次提交已被上游收录，git cherry-pick 会提示 empty commit，此时得手动 git cherry-pick --skip。更稳的方式是补丁法：
- 重置前先导出全部自研变更：
git format-patch upstream/dev-ai-contest-2026..zhanma666-dev-ai-contest-2026 - 重置后用
git am *.patch逐个应用，失败时可人工编辑 patch 文件再重试 - 补丁法不依赖提交哈希链，只比对变更内容，绕过了合并提交、空提交、祖先偏移等所有历史结构问题
PR 冲突消除后仍推送失败？检查 .gitignore 和缓存文件
即使历史对齐了，git push 仍可能被拒，常见干扰项是未跟踪的垃圾文件污染工作区。Jupyter 项目常带 .ipynb_checkpoints/ 目录，它虽不参与 Git 提交，但会被 git status 列出，某些 CI 流程或 pre-push hook 会把它当异常项拦截：
- 运行
rm -rf .ipynb_checkpoints/彻底清理 - 追加忽略规则：
echo ".ipynb_checkpoints/" >> .gitignore && git add .gitignore && git commit -m "ignore jupyter checkpoints" - 注意：不要用
git clean -fd直接扫目录，它可能误删你还没git add的临时文件
分叉冲突的本质是历史拓扑问题，不是文本差异问题。修复的关键在于放弃“合并”思维，转向“基线重置+变更重放”。任何试图在分叉基础上做 rebase 或二次 merge 的操作，都只是把问题往后推了一次。
