git rebase冲突时终端提示显示当前卡住的提交哈希（如fa39187），并要求执行git rebase --continue继续、--skip跳过或--abort中止；运行git status可定位冲突文件，其内含<<<<<<< HEAD、=======、>>>>>>>标记，需手动编辑保留合理代码并删除标记，再git add标记解决。
git rebase 出现 conflict 时终端提示怎么看
变基过程中一旦冲突，Git 会立刻停在出问题的提交上，并输出类似这样的信息：
error: could not apply fa39187 something to add to patch A When you have resolved this problem, run "git rebase --continue". If you prefer to skip this patch, run "git rebase --skip" instead. To check out the original branch and stop rebasing, run "git rebase --abort".
关键点有三个：
-
fa39187是当前卡住的提交哈希，说明是这个提交引入了与目标分支的冲突 -
git rebase --continue是解决后必须执行的命令，不是可选操作 -
git rebase --skip会丢弃该提交全部改动，除非你确认它无用，否则别碰
如何定位并编辑冲突文件
运行 git status，你会看到类似：
Unmerged paths:
(use "git add <file>" to mark resolution)
both modified: src/utils.js
both modified: README.md
这些就是需要手动处理的文件。打开任一文件，你会看到标准冲突标记：
<<<<<< HEAD
export function formatTime() { ... }
=======
export function formatTime(ts) { return new Date(ts).toISOString(); }
>>>>>> 7a2b1c4 feat: add timestamp support
其中：
-
<<<<<< HEAD下方是目标分支（比如main）已有的内容 -
=======是分隔线 -
>>>>>> 7a2b1c4下方是你当前提交的改动
删掉所有标记行（<<<<<<、=======、>>>>>>），只保留逻辑正确、能跑通的代码。
解决完一个冲突后为什么不能直接 push
因为 git rebase 本质是重写历史：每个被搬运的提交都会生成新哈希（如 D'、E'），原始提交已失效。此时如果远程已有旧版本分支，直接 git push 会被拒绝：
! [rejected] feature -> feature (non-fast-forward)
必须强制推送，但推荐用更安全的方式：
- 用
git push --force-with-lease，它会检查远程分支是否被别人更新过，避免覆盖他人工作 - 绝对不要对已共享的公共分支（如
main、develop）做rebase后强推 - 如果分支已被多人基于开发，应改用
git merge同步，而非事后补rebase
VS Code 内置合并工具怎么配合 rebase 使用
VS Code 在检测到冲突文件时，底部状态栏会显示「Accept Current Change / Accept Incoming Change / Accept Both Changes」等按钮，点击即可快速选择。但注意：
- 它不会自动帮你删掉冲突标记行，必须手动确认或清理残留
- 选完后仍需执行
git add <file>标记为已解决，否则git rebase --continue会报错 - 如果多个文件冲突，VS Code 只高亮当前打开的文件，别漏掉
git status列出的其他文件
最易被忽略的是：每次 git rebase --continue 后，Git 会尝试应用下一个提交——它可能再次触发冲突。整个过程是逐个提交推进的，不是“解决一次就全完”。
