rebase 出错后应优先用 git reflog 找回 rebase 前位置并 reset，若已 push 则用 rebase –abort 或 git revert 补救，force-push 仅限无人基于该分支工作的极端情况。
rebase 后发现搞错了，怎么立刻撤回
能撤，但得看“错”到哪一步——如果还没 push，本地直接重置就行；如果已经 push 且别人拉过，就不能硬重置，得用 git revert 补救。
最安全的兜底动作是：先查 git reflog，它会记下每次 HEAD 变动，包括 rebase 前的位置。找到 rebase 开始前那条记录（通常标着 HEAD@{n}），就能精准跳回去。
-
git reflog看最近操作，找带rebase start或明显早于 rebase 的那行 - 确认后执行
git reset --hard HEAD@{n}（n换成对应数字） - 如果 rebase 中途被中断（比如冲突没解决完就退出），
git rebase --abort是最快解法，不用翻 reflog
已经 push 了，还能 force-push 覆盖吗
技术上可以，但风险极高——只要有人在你 force-push 前 git pull 过旧分支，他的本地历史就会和远程不一致，后续 pull 会出一堆合并冲突，甚至丢提交。
团队协作中，force-push 已 rebase 的分支属于“破坏性操作”，除非你 100% 确认没人基于它工作，否则别碰。
- 查谁可能依赖：
git branch -r --contains <old-commit-hash>（用 reflog 找到 rebase 前的 commit hash） - 更稳妥的做法：用
git revert把 rebase 引入的每个新提交都反向提交一次，生成可预测、可审计的撤销记录 - 如果必须 force-push，先
git push --force-with-lease，它比--force多一层保护：远程分支没被别人更新时才允许覆盖
rebase 过程中卡在冲突里，想放弃但又怕丢修改
rebase 冲突时，工作区的代码改动还在，只是暂存区和 HEAD 被暂停了。此时 git rebase --abort 不会丢你改的文件内容，只会把分支指针和索引恢复到 rebase 前状态。
真正要小心的是：手动删了冲突标记后乱 git add 或 git commit，这会让 rebase 流程彻底混乱，reflog 里也难定位。
- 冲突时别急着改代码，先
git status看哪些文件 Unmerged - 解决完一个文件，
git add <file>，再git rebase --continue - 不确定怎么解？
git rebase --skip会跳过当前提交（慎用，可能丢逻辑），--abort是无害的退出键
为什么 reflog 是 rebase 撤销的核心依据
因为 rebase 本质是“复制提交 + 移动分支指针”，原提交不会被删，只是暂时不可达。reflog 是唯一默认开启、不依赖远程、只存本地的“操作时间线”，比 git log 或 git fsck 更快更准。
但它不永久保存（默认 90 天），也不同步到远程，所以不能当长期备份用。
-
git reflog show main可单独看某分支的 reflog，避免被其他分支日志干扰 - 如果 reflog 被清过（比如执行过
git reflog expire --all），就得靠git fsck --lost-found找悬空对象，成功率低很多 - 日常建议：对重要分支做 rebase 前，先
git tag backup-pre-rebase，比依赖 reflog 更可控
reflog 不是万能的，它只帮你回到“rebase 开始前”，但如果你在 rebase 过程中又做了其他提交、切换了分支，reflog 条目会变多，找错 HEAD@{n} 就容易翻车——这时候别猜，用 git log --oneline --graph --all 对照着 reflog 一起看。
