根本原因是git只认git add的暂存动作，不认文件内容变化；必须对每个冲突文件单独执行git add ，使其状态变为“to be committed”，才能执行git rebase --continue。
git rebase --continue 报“No changes - did you forget to use 'git add'?”
这是最常卡住的地方：你删掉了 、<code>=======、>>>>>>，保存了文件，但执行 git rebase --continue 时 Git 依然拒绝继续，并抛出这句提示。
根本原因不是代码没改对，而是 Git 根本没“看到”你已解决冲突——它只认 git add 的暂存动作，不认文件内容变化本身。
- 必须对每个冲突文件单独执行
git add <file></file>（不能只git add .，尤其当有未跟踪文件或误删文件时） - 如果用 VS Code 内置的“Accept Current Change”等按钮，它们只是编辑文本，不会自动
git add -
git status输出中，冲突文件应从 both modified 变为 to be committed，这才是真正就绪的状态
rebase 过程中出现多个冲突轮次（如 Rebasing (2/5)）
rebase 不是单次冲突事件，而是按提交顺序逐个重放。如果你的分支有 5 个待变基提交，就可能遇到最多 5 轮冲突，每轮都需独立解决。
常见误解是“解决完第一个冲突就完了”，结果执行 git rebase --continue 后终端显示 Rebasing (2/5)，接着又报新冲突——这不是失败，是流程正常推进。
- 每次冲突后，Git 会暂停并提示当前进度（如
Rebasing (3/5)），注意看这个数字是否递增 - 不要在解决第 1 个冲突后就退出终端或切换分支，否则容易丢失上下文
- 若某一轮冲突解决后，
git rebase --continue立即又进下一轮冲突，说明前一个提交的变更影响了后续补丁的上下文（比如删了一个函数，而下一个提交又试图修改它）
误用 git rebase --skip 导致逻辑丢失
git rebase --skip 不是“跳过这次冲突”，而是彻底丢弃当前正在重放的那个提交的所有变更，包括 git rm、权限修改、配置项增删等隐性操作。
它适合极少数场景（比如调试用的临时打印语句提交），但绝不该用于功能代码、修复补丁或 CI 配置类提交。
- 被
--skip的提交不会出现在最终历史里，且无法通过后续--continue恢复 - 如果该提交含
git rm src/legacy-api.js，跳过后文件不会删除，但后续提交若依赖此删除（比如新增同名模块），就会引发运行时错误 - 真要丢弃某个提交，请改用
git rebase -i，在编辑器中直接删掉对应行，再保存退出
VS Code 合并工具与 rebase 冲突不兼容的细节
VS Code 的“Merge Editor”默认为 git merge 设计，对 git rebase 的多轮状态支持有限。它可能正确高亮冲突，但无法感知当前处于哪一轮重放，也不提供“标记本轮已解决”的快捷入口。
更麻烦的是：某些扩展（如 GitLens）在 rebase 状态下会禁用部分功能，或把 .git/rebase-merge 目录误判为异常。
- 建议在 rebase 期间关闭所有 Git 相关扩展，仅用原生编辑器+终端配合
- 打开冲突文件后，手动搜索
定位，删标记 → 保存 → 终端执行 <code>git add <file></file>→git rebase --continue - 如果已用 VS Code 打开多个冲突文件，务必确认每个都完成
git add，漏一个就会卡住整个流程
真正容易被忽略的点在于：rebase 冲突不是“一次解决所有文件”，而是“一次解决一个提交里的所有冲突文件”，且每个提交彼此隔离。你可能改了 3 个文件才解决第 1 个提交的冲突，但第 2 个提交又会重新要求你处理其中 1 个文件——因为它的补丁是基于旧版本生成的，和当前工作区已不同。
