WebStorm Git 一直显示 rebasing 的解决办法

tip

首先确认代码没问题，git rebase 的相关操作确实已经完成

找到 .git 文件夹
找到 rebase-*** 相关的文件夹，如下图

删除此文件夹

那个文件夹是什么

.git/rebase-merge/ 和 .git/rebase-apply/ 是 rebase 的进度记录目录。rebase 本质上是「把一串提交逐个重放到新基底上」，中间可能因为冲突停下来等你处理，所以 git 需要把状态落盘：

.git/rebase-merge/：交互式 rebase（rebase -i）和默认的 merge 策略使用。里面的 git-rebase-todo 是待处理的提交清单，done 是已完成的，onto 是目标基底，head-name 是原分支名。
.git/rebase-apply/：rebase --apply（老的 am 策略）和 git am 使用。

WebStorm 判断「当前是否在 rebase 中」看的就是这两个目录是否存在——这和 git 自己的判断逻辑一致，git status 里那句 interactive rebase in progress 同样来自这里。所以目录残留时，不只 WebStorm，命令行也会认为你还在 rebase 中。

残留的原因通常是 rebase 过程被非正常打断：手动删了冲突文件、强行杀掉 git 进程、IDE 崩溃、或者在 rebase 中途执行了 git checkout 切走。

先用 git 自己的命令收尾

直接删目录是最后手段。优先让 git 自己清理，因为它除了删目录还会正确处理 HEAD、ORIG_HEAD 和引用状态：

# 先看清 git 认为自己在什么状态
git status

# 如果确实还有未完成的步骤，继续走完
git rebase --continue

# 想跳过当前这个提交
git rebase --skip

# 放弃整个 rebase，回到 rebase 开始前的状态
git rebase --abort

--abort 是最常用的出路，它会把 HEAD 和分支都恢复到 rebase 之前，工作区一并还原。前提是 .git/rebase-merge/orig-head 还完好——这个文件记着起点，坏了或没了 --abort 就会失败，那时才轮到手动删目录。

原文强调「先确认代码没问题、rebase 相关操作确实已完成」，这一点很关键。如果实际上 rebase 没走完就删目录，会留下一个尴尬的中间状态：HEAD 指向重放到一半的位置，部分提交已经在新基底上、部分还在原分支上。所以删之前一定先确认：

# 当前 HEAD 在哪
git log --oneline -5

# 分支引用在哪（和 HEAD 对比，看是不是分离状态）
git branch -v
git rev-parse HEAD
git rev-parse --abbrev-ref HEAD    # 输出 HEAD 说明处于 detached 状态

# 完整的操作历史，能看到 rebase 的每一步
git reflog -20

git reflog 是这类场景的救命工具。它记录了 HEAD 的每一次移动，rebase 开始前的位置一定在里面（标着 rebase (start) 或者原本的提交），确认好了随时能回去：

git reset --hard HEAD@{5}

手动清理的完整步骤

确认过状态、--abort 也用不了的话，按这个顺序来：

# 1. 先记下 rebase 之前的位置，以防后面要回退
git reflog -20 > /tmp/reflog-backup.txt

# 2. 用 git 的路径而不是相对路径（worktree / submodule 安全）
GIT_DIR=$(git rev-parse --git-dir)

# 3. 删掉进度目录
rm -rf "$GIT_DIR/rebase-merge" "$GIT_DIR/rebase-apply"

# 4. 如果 HEAD 处于分离状态，切回到目标分支
git checkout master

# 5. 确认状态干净
git status

第 4 步容易漏。rebase 期间 HEAD 是分离的（detached），删了进度目录之后 git 不再认为你在 rebase，但 HEAD 仍然分离着。这时候提交会成为不属于任何分支的孤立提交，很容易丢。

MERGE_HEAD、CHERRY_PICK_HEAD、REVERT_HEAD 是同类的状态文件，对应 merge / cherry-pick / revert 卡住的情况，处理思路完全一样——优先用 git merge --abort、git cherry-pick --abort、git revert --abort，实在不行才手动删。

WebStorm 侧的缓存

有时候目录已经删了、命令行 git status 也干净了，WebStorm 的 Git 面板还显示 rebasing。这是 IDE 自己的状态缓存没刷新，试这几个：

右键项目 → Git → Repository → 或者顶部菜单 Git → 点一下 Fetch，触发一次状态重读。
File → Reload All from Disk（Cmd/Ctrl + Alt + Y），强制重扫文件系统。
File → Invalidate Caches / Restart，最彻底。
重启 IDE。

反过来也提醒一句：IDE 里的 git 操作和命令行操作不要交叉进行。WebStorm 的 rebase 是它自己的进程在跑，中途在终端里执行 git 命令很容易互相踩，这本身就是产生残留目录的常见原因。要么全用 IDE，要么全用命令行。

少踩这个坑的习惯

rebase 之前先打个标记。 一个分支名或 tag 就够，出问题直接回到那里，比翻 reflog 直观：

git branch backup/before-rebase
# 搞定之后删掉
git branch -D backup/before-rebase

开启 rerere。 反复 rebase 长期分支时，同样的冲突会重复出现，rerere 记住解法之后自动套用，能大幅减少中途卡住的次数：

git config --global rerere.enabled true

改用 git worktree 做并行工作。 rebase 卡住时想去看别的分支，不要在同一个工作区里 git checkout 切走（这是产生残留状态的高频原因），而是新开一个工作树：

git worktree add ../project-hotfix master

两个目录各自独立的工作区和 index，互不干扰。