PR显示“conflict”但本地git merge提示“Already up to date”，是因为rebase重写了feature分支提交哈希，导致与origin/main失去共同祖先，GitHub无法计算merge base而误报冲突；验证可用git merge-base feature/login origin/main，若无输出即证实该问题。
PR页面显示“conflict”但本地 git merge 提示 already up to date
这是变基后最典型的假性冲突：GitHub 比对的是提交历史的共同祖先（merge base），不是文件内容。你执行了 git rebase main，本地 feature/login 的所有提交都被重写成新哈希，导致它和 origin/main 失去共同祖先。GitHub 无法自动计算合并基础，于是直接标红 “conflict”。
验证方式很简单：
- 运行
git merge-base feature/login origin/main—— 如果返回空，说明确实无共同祖先 - 对比
git log --oneline -n 5 origin/main和git log --oneline -n 5 feature/login，哈希值几乎肯定完全不同 -
git show-branch origin/main feature/login会显示两分支完全分离，没有 * 标记交汇点
用 reflog 找回被覆盖的原始提交
只要还没执行 git gc 或长时间未操作，reflog 通常能找回 rebase 前的提交。关键不是找“功能代码”，而是找“你 push 之前那个 HEAD 状态”。
执行以下命令：
-
git reflog—— 查看操作历史，重点找带rebase或pull关键字的行 - 找到类似
a1b2c3d HEAD@{3}: pull origin main: Fast-forward这样的记录，它代表 rebase 前你最后一次干净同步的状态 - 用
git reset --hard HEAD@{3}直接回退到该状态（注意：这会丢弃 rebase 过程中产生的新提交）
如果 reflog 已被清理，但其他协作者本地还有旧提交，可请他们运行 git rev-parse feature/login 并把哈希发给你，再用 git fetch origin <hash>:refs/remotes/origin/feature-login-old</hash> 拉取回来。
强制推送后如何安全恢复远程分支
一旦执行了 git push --force，origin/feature/login 就已丢失原历史。此时不能简单 git push，否则会再次覆盖。
正确做法分两步：
- 先用
git push --force-with-lease origin feature/login—— 它会检查远程分支是否真的比你本地“旧”，避免覆盖别人新推的提交 - 如果失败（提示 remote ref is newer），说明有人在你 force 之后又推过。这时必须协调：让对方暂存本地变更，你先恢复远程，再让他们
git pull后重放变更 - 恢复完成后，立刻在 Git 服务端（如 GitHub/GitLab）将该分支设为 protected，并禁用
Allow force pushes
后续 PR 应该用 merge 而不是 rebase
公共分支上的 PR，目标是“集成结果正确”，不是“历史看起来线性”。merge 提交虽多一个节点，但它明确标记了集成时刻、谁合入、基于哪个基础 —— 这些信息在排查 CI 失败或线上问题时至关重要。
真正需要 rebase 的场景极少，仅限于：
- 你的 feature 分支尚未 push 到远程，纯本地整理
- 团队明确定义了“仅允许 rebase + force-push”的内部流程，且全员装有
rerere.enabled - 维护长期私有分支（如个人 fork 的 dev 分支），且不与其他开发者共享该分支的提交哈希
变基真正的代价不在操作本身，而在它抹掉了“这个提交是在哪一刻、基于哪个状态产生的”这一事实。而这个事实，往往在出问题时才被发现已经没了。
