rebase中断后应先用git status确认状态，冲突解决后执行git add和git rebase --continue继续；若已--abort，可通过git reflog定位原分支头并git reset --hard恢复。
rebase 中断后如何恢复继续
Git 变基（git rebase）中途失败（比如冲突未解决、编辑器异常退出、或手动执行了 git rebase --abort 以外的误操作），当前状态会停留在「rebase in progress」，.git/rebase-apply 或 .git/rebase-merge 目录仍存在。此时不能直接 git commit 或 git push，否则可能破坏变基流程。
正确做法是先确认状态：
- 运行
git status—— 若显示rebase in progress，说明尚未中止 - 检查
git log --oneline -n 5是否还停留在原分支头，而非变基中的临时提交 - 查看
cat .git/rebase-apply/head-name（或.git/rebase-merge/head-name）确认目标分支名
若冲突已解决，只需：
-
git add <file></file>标记已解决的文件 -
git rebase --continue继续变基流程
rebase --abort 之后还能找回原始分支吗
能。只要没执行 git reset --hard 或删掉 reflog，原始分支指针仍在 git reflog 中可追溯。
典型场景：你从 feature 分支对 main 执行 git rebase main，中途觉得不对，执行了 git rebase --abort。此时：
-
git reflog里会有一条类似HEAD@{0}: rebase (abort): updating HEAD，往上翻能找到HEAD@{1}: checkout: moving from feature to feature或更早的feature分支头 - 用
git reset --hard HEAD@{1}即可恢复到 rebase 开始前的状态 - 如果原始分支名已丢失（比如被重命名或删除），可用
git branch feature-backup HEAD@{1}新建备份分支
注意：git rebase --abort 不会删除未提交的修改，但会丢弃所有已 add 但未 rebase --continue 的暂存变更 —— 这些变更其实还在工作区，只是 staging 被清空了。
对比基线与当前 GitHub Actions 运行导出，在 CI 成本和交付周期激增前及时发现工作流或作业运行时性能退化。
冲突解决后误用了 git commit 而非 git rebase --continue
这是高频误操作：在 rebase 冲突状态下，直接 git commit 会生成一个普通合并提交，破坏变基线性历史，且后续 git rebase --continue 会报错 fatal: cannot resume interrupted rebase: you have unpushed commits。
补救方式分两种：
- 如果刚 commit 且没推送到远程：
git reset --hard HEAD~1回退这个错误提交，再git add+git rebase --continue - 如果已推送或不想改历史：
git rebase --skip强制跳过当前被 commit 干扰的提交（慎用，可能丢变更），或改用git rebase --edit-todo手动删掉那行 pick 记录
关键区别：git commit 在 rebase 中不是“提交解决”，而是“提交新快照”，它让 Git 认为当前步骤已完成，但语义上不属于 rebase 流程 —— 所以必须用 --continue 或 --skip 显式告知 Git 接下来怎么做。
rebase 中断后 stash 的内容去哪了
如果你在 rebase 开始前执行了 git stash，然后中断 rebase，stash 本身不受影响，仍可通过 git stash list 查看。但要注意：
-
git stash pop在 rebase 过程中可能触发额外冲突（因为工作区已被 rebase 修改） - 推荐先
git rebase --continue完成变基，再git stash pop；若必须提前还原，用git stash apply（不删 stash）并手动处理冲突 - 如果 rebase 中断时工作区有未暂存修改，它们会保留在工作区，但
git status显示的“Changes not staged”可能混着 rebase 前后改动，需比对git diff确认来源
最易被忽略的是：rebase 中断后，.git/rr-cache（rerere 缓存）依然有效，下次遇到相同冲突时仍会自动应用旧解决方案 —— 这点常被当成“Git 记住了”，其实是 rerere 在背后起作用，不是 rebase 自身能力。
