rebase冲突比merge更频繁，因其将当前分支各提交逐个重放到目标分支顶端，每个提交都可能因上下文变化独立触发冲突；而merge仅在合并点一次性三路比对。
rebase冲突为什么比merge冲突更频繁
因为 git rebase 不是一次性合并，而是把当前分支上每个提交逐个“重放”到目标分支顶端。只要目标分支已更新（比如 origin/main 新增了提交），而你的某个提交又恰好修改了被新提交动过的同一段代码，这个提交在重放时就会卡住并报冲突——哪怕你只改了一个文件里的一行，也可能触发多次冲突。
常见错误现象：error: could not apply abc1234... feat: 添加用户头像上传，接着看到一堆 <<<<<< HEAD 标记；或者刚解决完一个冲突，执行 git rebase --continue 后立刻又弹出下一个冲突。
- 这不是 Git 报错，是正常流程：每个提交都可能独立触发冲突
- 冲突发生在“重放该提交的补丁”阶段，不是整个分支一次性比对
- 如果你的 feature 分支有 5 个提交，而
origin/main已前进 3 次，最多可能遇到 5 次冲突
解决 rebase 冲突的三步实操流程
和 merge 冲突不同，rebase 冲突必须在每个提交层面闭环处理，不能跳过或批量解决。
- 看到冲突后，先用
git status查看哪些文件未合并（状态为both modified） - 手动编辑冲突文件，删掉
<<<<<< HEAD、=======、>>>>>> abc1234...这些标记，保留你想要的逻辑（注意：这里不是选 “ours/theirs”，而是根据业务意图融合） - 保存后执行
git add <file>（必须add，不能只commit），再运行git rebase --continue
如果中途想放弃，用 git rebase --abort 即可退回到 rebase 前的状态，不会丢提交。
什么时候不该用 rebase 解决冲突
rebase 的本质是改写本地提交历史。一旦你已经把分支推送到远程（git push origin feature），再本地 rebase 就会导致远程和本地的提交哈希不一致，后续 git push 会失败，必须加 --force-with-lease——但这会覆盖别人可能基于你旧提交做的工作。
- 团队协作中，如果
feature分支已被他人 checkout 或依赖，不要 rebase - 你的分支已通过 PR 提交审核，即使还没合并，也别 rebase（评审记录和评论会和旧提交绑定，变基后丢失上下文）
- 冲突涉及大量文件且逻辑耦合深（比如重构类名+接口+调用链），建议切回
git merge，避免在重放过程中反复中断、引入隐藏 bug
怎么提前降低 rebase 冲突概率
rebase 冲突多，往往不是 Git 的问题，而是分支生命周期管理松散导致的。关键不在“怎么解”，而在“怎么少遇”。
- 拉分支前先同步主干：
git fetch origin && git rebase origin/main（而不是等写完一堆再集中 rebase） - 单个提交职责单一：一个提交只做一件事（如只改 API 调用，不同时改 UI 和校验逻辑），这样冲突范围可控，重放失败时回滚成本低
- 避免长周期 feature 分支：超过 3 天没 rebase 主干的分支，冲突风险指数上升；每日至少一次
git pull --rebase（前提是没推远程）
最常被忽略的一点：rebase 解决的从来不是“代码差异”，而是“上下文漂移”。你写的第 3 个提交，是在第 1 个提交基础上改的；但 rebase 时，它要被挪到一个完全不同的基础之上——那个基础里，变量名可能已改，函数签名已变，甚至依赖库版本都不同。这才是冲突真正的源头。
