林杏仁上周帮同事处理了一个很典型的 Git 问题：执行完 git rebase main 之后，终端里 git status 直接刷出十几个未暂存文件，满屏红色的 modified。他当时的第一反应是 rebase 把代码搞坏了，文件是不是丢了。我看了一眼，反问了他一句：“你解决冲突的时候，是不是顺手改了别的文件？”他愣了几秒，然后想起来了：确实，冲突处理到一半，他手工调整了旁边两个无关文件，打算继续改完，结果忘了 git add 就直接 git rebase --continue 了。
这个场景再常见不过，而且本质上不是“文件被弄乱”，而是 rebase 的工作区状态和流程没对齐。这篇内容就围绕“Git Rebase 之后出现大量未暂存文件”展开，把常见诱因、排查思路、解决方案和预防习惯一次讲透。适合正被 rebase 后工作区异常困扰的开发者，也适合想更深入理解 rebase 状态流转机制的人。
1. 先看清现象：rebase 后“多出来”的未暂存文件是什么性质
1.1 rebase 机制下的工作区状态流转
Git rebase 和 merge 的本质区别，在于它会把当前分支的提交“摘下来”，再在目标提交之上按顺序逐个重放。每次重放一个提交时，Git 都在临时 HEAD 上操作，工作区目录则用来承载每个提交应用后的最新状态。等所有提交重放完毕，当前分支的 HEAD 指向新位置，工作区理论上应该和最终 HEAD 完全一致。
但“理论上”三个字就是坑。rebase 流程中，一旦某个步骤没有把工作区和索引同步好，状态就会留下尾巴。比如你手动修改了某些文件却没有 git add，这些改动在 rebase 结束时就不会被纳入要重放的提交，而是被原样留在工作区里。于是 rebase 完成后，你会看到一批莫名其妙的未暂存文件。
还有一个容易忽略的细节：rebase 重放提交的时候，Git 会把每个文件按新基底重新应用一遍。如果这个过程中有工具自动改了文件内容（IDE 的保存时格式化、lint 插件自动修复、行尾符转换），也会把本来不该变化的文件标记为 modified。所以出现未暂存文件，不一定是你自己的操作失误，环境差异和工具链因素占比也不小。
1.2 未暂存文件的三种来源分类
我把实际碰到过的 rebase 后未暂存文件问题归纳成三大类，判断时可以按这个框架走：
第一类，rebase 过程中残留的手工改动。冲突解决过程中，你随手调整了其他文件，但没 add；或者你用 mergetool 解决冲突时，mergetool 只处理了一部分文件，其他文件的改动原封不动留在工作区。这类文件在 rebase 完成后会全部显示为 modified，也是最常见的一类。
第二类，autostash 恢复不完整。git rebase --autostash 会把 rebase 前未提交的改动自动 stash 起来，rebase 结束后再自动恢复。但“自动恢复”不是百分百成功，如果恢复时和目标分支上的内容产生冲突，Git 会跳过自动应用，把 stash 条目留着，工作区里则留下冲突标记或者干脆一片空白，视觉上就是一堆未暂存文件。
第三类，环境差异导致的“伪改动”。文件本身的内容逻辑没变化，但 Git 认为它们变了。典型的诱因包括：行尾符 CRLF/LF 不统一、文件权限位（filemode）变化、子模块指针不一致、大小写敏感文件系统差异。这类问题最迷惑人，因为 git diff 打开看，不是全文件标记，就是完全看不出变化。
提示：判断问题时，不要一上来就
checkout .丢弃工作区改动。先看方向，后动手，否则很容易把真正需要的修改也冲掉。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 逐层排查：按顺序执行这几个命令，问题就清楚一半
2.1 git status 是第一步，也是读懂全局的关键
遇到 rebase 后未暂存文件，先别急着在网上搜，直接在终端敲 git status。重点看两件事：第一，rebase 是否已经结束；第二，文件是 modified 还是 untracked。
如果 git status 输出里出现类似 interactive rebase in progress; onto xxxxx 的提示，说明 rebase 还没走完，可能停在某个提交的冲突处理阶段，你需要先决定 continue、abort 还是 skip。如果没有任何 rebase 进行中的提示，rebase 已经完成，接下来要排查的是完成后的工作区残留。
然后再看文件分类。已经 tracked 却被修改的文件会列在 Changes not staged for commit 下面；之前从未被 Git 管过的新文件则列在 Untracked files 下面。这两种性质的“未暂存”，后续处理方式完全不同。新文件的处理思路通常是判断是否应该保留、是否要加入 .gitignore；已跟踪文件的处理则需要进入下一步，看 diff 内容。
2.2 git diff 系列：判断是真改动还是“伪改动”
只看 status 远远不够，因为 Git 报 modified 的原因可以很“虚”。这时候依次跑下面几个命令，能快速给问题定性：
bash复制git diff --stat
git diff --ignore-space-at-eol --stat
git diff --summary | head -50
git diff --stat 会列出每个文件的改动行数。如果所有文件都是整文件全量修改，行数非常夸张，那大概率是行尾符问题。git diff --ignore-space-at-eol 的输出如果突然变成空的，说明改动全都来自行尾差异，和真正的代码逻辑无关。git diff --summary 则可以发现文件 mode 的变化，比如 mode change 100644 => 100755，这种情况是典型的 filemode 问题。
还有一种方式很直接：打开 git diff <某个文件>，看具体 diff 内容。如果只是键盘上看不见的空白变化，Git 会把整行替换标记出来；如果是可执行位变化，diff 摘要会明说 mode change；如果 diff 结果为空但 git status 仍然显示 modified，就要怀疑索引和文件系统之间的元数据不一致，而不是内容变化。
2.3 检查 stash 和 rebase 残留状态
如果 status 显示的文件数量不多，但你又确实在 rebase 前带了未提交的改动，就一定要查 stash。
bash复制git stash list
看到类似 stash@{0}: On feature: autostash 这样的条目时，说明 rebase 自动 stash 了一个备份但没能自动恢复，需要手动处理。此时即便工作区看起来是干净的，stash 里也可能藏着旧的未提交改动，用 git stash show -p stash@{0} 可以查看内容，确认后决定 apply 还是 drop。
同时可以检查 .git/rebase-merge 或 .git/rebase-apply 目录是否存在。这两个目录只要存在，就代表 rebase 还处于进行中。就算 git status 提示信息不明显，这个目录依然是最可靠的判断依据。需要快速确认时，执行：
bash复制test -d .git/rebase-merge && echo "rebase-merge in progress" || echo "no rebase-merge"
组合使用 status、diff、stash list、rebase 目录检查，90% 的问题方向都能定位出来。
3. 分场景解决：不同诱因对应不同处理方式
3.1 场景一：冲突解决时残留的文件，先 add 再 continue
这是最常见的情况。冲突处理时，你手工调整了好几个文件，但只把其中一部分用 git add 标记为“已解决”。这样执行 git rebase --continue 时，Git 检查到当前提交的冲突文件都已经 add，于是会继续流程。剩下没 add 的文件，就被当成普通的未暂存修改，完整保留到 rebase 之后。
处理方式很简单：先 git status 确认当前 rebase 状态和文件列表，然后对需要保留的文件执行：
bash复制git add <文件路径>
git rebase --continue
如果不确定哪些文件属于这个提交，可以直接 git add -A 把当前所有改动纳入暂存区。但我要提醒一句：git add -A 会把所有新文件也加进去，如果里面混了一些你自己都记不清的临时文件，谨慎点，逐个 add 更安全。add 完成后，rebase 会继续重放剩余提交，之后再次 git status 确认工作区是否恢复到干净状态。
如果你觉得冲突文件太多、不想逐个处理，立刻回到 rebase 之前的状态，用 git rebase --abort 最稳妥。它能撤销本次 rebase 带来的所有变化，让分支和工作区恢复到执行 rebase 前的那一刻。不过注意，abort 只适合确定要放弃本次 rebase 时使用，已经手动解决到一半的冲突代码也会被丢掉。
3.2 场景二：--autostash 恢复不完整，手动找回 stash
启用 --autostash 后，Git 在 rebase 前会自动把未提交的改动藏起来。正常流程下，rebase 结束时会自动恢复正常，但以下几种情况会失败：
- rebase 重放后某个提交触碰了同一个文件，自动恢复产生冲突；
- 网络或文件系统异常导致恢复流程中断；
- 你中途执行了
git rebase --abort，abort 会恢复 stash，但某些情况下状态会错乱。
此时 git stash list 里能看到一个明确写着 autostash 的条目。手动恢复的步骤是：
bash复制git stash apply stash@{0}
如果 apply 时报冲突，就先把冲突解决掉，确认无误后用 git stash drop stash@{0} 清理这个 stash，避免下次操作时又翻出来。如果没有冲突，apply 成功后也可以直接 drop，让 stash 列表保持干净。
极端情况下，如果这个 autostash 被误删了，可以用 git fsck --lost-found 查找游离的 commit，也可以查看 stash 的 reflog 找回对应的 commit hash：
bash复制git reflog show stash
stash 本质上是一个特殊的 commit，只要哈希还在，就能通过 git cherry-pick <hash> 或者手工 git show 取回内容。这条技巧关键时刻很救命，但也提醒我们：autostash 的自动机制虽方便，依赖它之前最好先明确知道 stash 条目在哪里。
3.3 场景三：行尾符导致“一片红”，统一换行策略
在 Windows 上开发，Linux 上部署，或者团队里有人开了自动转换行尾的编辑器，rebase 之后大量文件显示 modified 的“重灾区”基本就是行尾符问题。
先解释一下机制。Git 的 core.autocrlf 选项控制行尾符转换行为：
true：提交时把 CRLF 转成 LF，检出时再把 LF 转成 CRLF，主要面向 Windows 场景；input：提交时转 LF，检出时不做转换，适合跨平台但主要在类 Unix 环境使用；false：不做任何转换，文件以什么形式入库，就以什么形式检出。
仓库内部通常存的是 LF，如果你本地工作区的文件是 CRLF，而某个 rebase 步骤强制重新生成了这些文件，Git 对比时就会认为每个文件都变了，于是出现大量未暂存文件。判断方法就是前面说的 git diff --ignore-space-at-eol --stat 输出为空。更细致地验证可以执行：
bash复制git ls-files --eol
输出里 i/ 表示仓库索引中的行尾符，w/ 表示工作区的行尾符。看到 w/crlf 一堆、i/lf 一堆，那就是行尾符差异无误。
解决方案要从根上统一：在仓库根目录放一份 .gitattributes，明确声明各类型文件的规范化规则：
gitattributes复制* text=auto
*.java text
*.js text eol=lf
*.sh text eol=lf
*.png binary
规则写好后，执行 git add --renormalize . 让所有文件按新规则重新规范化，然后提交一次名为“Normalize line endings”的变更。这次提交可能改动一大堆文件，但从长远看，它能消除团队协作里八成以上的行尾符问题。
3.4 场景四：文件权限变成 modified，关闭 filemode 检测
如果你所在的环境是 Windows、FAT/NTFS 挂载盘、或者某些 CI 容器，会发现 rebase 后 git status 显示大量 modified，但 git diff 的内容又是空的。这时候重点看一下 git diff --summary 的输出，如果有很多 mode change 100644 => 100755 或反向变化，就是 filemode 在捣乱。
Git 会记录文件的可执行位，默认情况下 core.filemode=true 时，会把索引里的权限和工作区的权限做强校验。在某些文件系统里，权限位本来就不稳定，比如挂载时被统一设置成了 644 或 755，Git 就会把这种差异识别为文件修改。
解决方式非常简单：
bash复制git config core.filemode false
配完之后，git status 里由权限位导致的 modified 会全部消失。如果项目里有人已经提交了 mode change，导致历史里残留无意义的权限变更，可以考虑单独处理一次，把权限位恢复正常，避免后续 diff 里反复出现 mode change 噪音。
这个配置可以设置在全局，也可以只对当前仓库生效。我的建议是：跨平台协作的项目，直接在仓库的 .git/config 里设置，同时同步到团队文档；如果你经常访问 FAT/NTFS 挂载盘，全局设成 false 更省心。
3.5 场景五：子模块、大小写等边界情况
除去上面几个主流的诱因，还有两类不太常见但碰到就容易懵的情况。
第一类是子模块问题。当 rebase 更新到一个包含子模块指针变化的提交时，子模块目录本身的内容不会自动更新。此时 git status 会在子模块目录下显示 modified，处理方式是进入子模块目录后手动 git checkout <期望的提交>，或者在仓库根目录执行：
bash复制git submodule update --init --recursive
第二类是大小写敏感文件系统差异。macOS 和 Windows 默认不区分文件名大小写，Linux 区分。如果 rebase 过程中引入了只修改文件名大小写的提交，在 macOS 上可能会看到文件同时出现在 staged 和 unstaged 两处，或者出现找不到文件、无法 checkout 的怪象。这类问题最好通过规范命名约定来规避，真要处理时可以用 git mv 分两步重命名，先改成临时名，再改成最终名，绕过大小写不敏感的坑。
4. 实操案例复盘：一次完整的排查到解决全过程
4.1 案例背景和初始状态
为了把这些思路串起来，我复现一个最近帮同事排查的真实场景：
他在 feature/login 分支上，执行了 git rebase main。过程中有两个提交都出现了冲突，他花了不少时间手动编辑文件，用 VS Code 逐个解掉。解完第一个冲突后，他直接执行 git rebase --continue；到第二个冲突时，他又改了几个文件，其中一个文件本不属于冲突范围，是他顺手调整的格式，接着继续 rebase 直到结束。最终 rebase 显示成功，但 git status 刷出来 9 个 modified 文件。
他当时的疑问是：rebase 明明成功，为什么还有这么多文件处于修改状态？我接手后的第一件事就是看 git status 的完整输出。
4.2 排查思路详细走查
git status 输出没有 “rebase in progress” 提示，说明 rebase 流程已经走完。9 个 modified 文件里，有 6 个是冲突时手工编辑过的，3 个是他后来顺手改的格式文件。
我接着跑 git diff --stat，发现所有文件改动都集中在冲突文件上，格式文件显示的改动行数很少。再用 git diff --ignore-space-at-eol --stat 对比，输出没有变为空，说明不是行尾符问题。git diff --summary 也没有出现 mode change，所以 filemode 可以排除。
然后我检查了 git stash list，输出为空，autostash 这条线也排除了。剩下的判定就非常清晰：这些未暂存文件，就是冲突解决过程中未 add 的残留改动。他用 mergetool 或手工编辑时，只关注了冲突标记本身，改完把文件保存后没有执行 git add，Git 自然不知道这些文件的冲突已解决，rebase 后就把它们当作普通工作区改动保留了下来。
4.3 最终定位与处理结果
定位之后处理很简单：确认这些残留改动都是他想要的，然后批量 git add，提交生效。
bash复制git add -A
git commit -m "resolve rebase leftovers"
一次性把所有未暂存文件变成一个新的提交，比反复 git rebase --continue 更干净，也方便以后 review。他确认提交内容无误后 push 到远端，整个工作区恢复干净，问题闭环。
这次排查让我更确定了一点：rebase 本身不会造成文件丢失，造成困惑的往往是流程中断后的人为残留。遇到这类问题，先冷静看 status，再对照 diff 排除“伪改动”，绝大多数情况下十分钟内就能定位清楚。
5. 预防方案：在下次 rebase 之前做好这几件事
5.1 rebase 前强制检查工作区状态
绝大多数 rebase 后未暂存文件问题，都可以在 rebase 之前避免。最简单的习惯是：执行 rebase 前先看一眼工作区状态。
bash复制git status --porcelain
如果输出非空，说明存在未提交改动，此时先别急着 rebase。你可以选择把这些改动提交成一个 WIP commit，也可以先 git stash 临时收起来。不要依赖 --autostash，虽然它方便，但如果恢复过程中有冲突，你又要多处理一轮状态问题，反而不划算。
在团队层面，还可以配置 pre-rebase hook，自动检查工作区是否干净，非干净状态直接阻断 rebase：
bash复制#!/bin/sh
if ! git diff --quiet || ! git diff --cached --quiet; then
echo "working directory is not clean, abort rebase" >&2
exit 1
fi
这个 hook 的成本很低，却能拦截掉很多“一时手快”造成的状态混乱。
5.2 用 WIP commit 管理未完成改动
我不太建议长期用 stash 堆积未完成的改动，因为 git stash list 里超过三四个条目后，基本就要靠猜来判断哪个是对的。相比之下，一个临时的 WIP commit 更直观：
bash复制git add -A
git commit -m "WIP: temporary save"
git rebase main
# 处理完 rebase 后再决定保留或撤销
git reset --soft HEAD~1
reset 之后，WIP commit 的内容会回到暂存区，不会丢失。如果你发现 rebase 后这些改动的确不需要了，直接 git reset --hard HEAD~1 丢掉即可。这套方法比 stash 更清晰，尤其是当 rebase 需要很长时间、中间还夹杂着几次冲突处理时。
5.3 统一工具链与仓库属性
前面提到行尾符和文件权限问题，都是在环境差异积累到一定程度后集中爆发的。要真正避免，靠的是一套团队级的基础设施配置：
- 仓库根目录放
.gitattributes，限定常见文件类型的行尾符； - 用
.editorconfig统一编辑器的缩进、字符集、换行设置； - 关掉 IDE 里“保存时自动格式化整个文件”的选项，至少对大型老项目要谨慎；
- 跨平台协作者在各自环境中确认
core.autocrlf、core.filemode的取值。
前期做这些标准化工作时会“嫌弃”它无关紧要，但真等到 rebase 后满屏 modified 出现，再反过来补配置，成本会高很多。而且这类配置属于一次投入、长期受益。
5.4 约定 rebase 后的快速自检流程
团队内部可以约定一套 rebase 后的自检动作：执行完 git rebase main，第一时间 git status，确认没有未暂存文件；有的话对照 diff 判断是内容残留还是环境差异；如果是环境差异，检查 .gitattributes 和 core.autocrlf 是否配置正确；如果是内容残留，逐个确认保留还是丢弃。
把这个流程固化为习惯之后，rebase 后出现异常不会再让人恐慌，而是变成一次平稳的常规检查。
6. 常见问题速查表
| 现象 | 可能原因 | 快速处理 |
|---|---|---|
| rebase 完成后大量文件 modified，diff 内容真实存在 | 冲突解决时未 add 全部文件 | 确认改动后 git add，然后 git rebase --continue 或提交 |
大量文件 modified，git diff --ignore-space-at-eol 为空 |
行尾符 CRLF/LF 不统一 | 配置 .gitattributes，执行 git add --renormalize . |
大量文件 modified，但是 git diff 无内容变化 |
文件权限位 filemode 变化 | git config core.filemode false |
| status 提示 rebase in progress | 上次 rebase 未正常完成 | 评估后选择 --continue、--skip 或 --abort |
| stash list 存在 autostash 条目 | autostash 恢复失败或冲突 | git stash apply 后解决冲突，再 git stash drop |
| 子模块目录显示 modified | rebase 更新了子模块指针，但本地子模块未同步 | git submodule update --init --recursive |
| 文件大小写显示异常 | macOS/Windows 大小写不敏感文件系统 | 用 git mv 分两步重命名，规范命名约定 |
| 怀疑 stash 被误删 | stash 本质是 commit，可找回 | git fsck --lost-found 或 git reflog show stash |
排查的时候按这个表对照走，能省下不少时间。表里列的都是我已经实际遇到并验证过的方案，不是纸面推断。
最后再分享一个我个人的习惯：每次 rebase 前，我会先在脑子里过一遍“工作区干净吗、改动要不要留、目标基底对不对”三个问题。确认没问题才执行。出现未暂存文件时，先看 status、再看 diff、最后动工作区，这个顺序一次都不要颠倒。Git 的状态管理虽然灵活，但只要遵循“先确认后操作”的原则，就不会被这些小问题绊住手脚。