必须手动删净冲突标记：残留<<<<<<<、=======或>>>>>>>任一符号，文件即未解决，git commit将失败；可靠检查方式为grep -n "<<<<<<" <file>定位残留，且需注意空行、注释、缩进等易漏细节。
冲突标记必须手动删干净，Git 不会替你擦屁股。 只要文件里还残留 <<<<<< HEAD、======= 或 >>>>>> branch-name 中的任意一个，这个文件就仍算“未解决”，git add 会成功，但 git commit 会失败或留下无效提交。
怎么识别残留的冲突标记
别只盯着编辑器高亮区域——VSCode 或其他 IDE 有时只高亮当前打开的冲突块，而忽略被你误删一半、只剩 >>>>>> 的残骸。最可靠的方式是命令行检查：
- 运行
git status，确认所有冲突文件已进入 staged 状态（即绿色显示）；如果还有红色（unmerged），说明没处理完 - 用
git diff --cached <file>查看暂存区内容，搜索<<<<<<—— 若有输出，说明标记没清干净 - 在终端直接
grep -n "<<<<<<" <file>，逐行定位残留位置
清理时最容易漏掉的三种情况
很多人以为删掉三段标记就完事了，其实下面这些细节常被跳过：
- 空行残留：删完
=======后，前后多留了一行空行，导致函数签名和 body 之间多出空行，语义虽不变，但可能触发 linter 报警或格式化工具重排 - 注释错位：原冲突块里有行内注释（如
return a + b; // local calc），手动保留逻辑后忘了把注释移到新代码行末，结果注释挂在了上一行或下一行，语义断裂 - 缩进不一致：两边分支用了不同缩进风格（4空格 vs tab），合并后手动拼接时没统一，造成语法错误或 PEP8/ESLint 失败
为什么不能靠 git checkout --ours 或 --theirs 一劳永逸
这两个命令确实能一键覆盖整份文件，但它们只适合“全盘接受某一方”的极简场景：
-
git checkout --ours <file>会丢弃对方所有修改，包括你没注意到的 bug 修复、日志埋点、安全补丁 -
git checkout --theirs <file>同理，会抹掉你本地尚未 push 的业务逻辑变更 - 对含多个冲突块的文件，它无法做“这块留 ours，那块选 theirs”式的混合决策——而现实中，90% 的冲突都需要融合而非取舍
真正难的不是删标记，是判断哪段逻辑该留、哪段该改、哪段要重写。标记只是 Git 拉的警戒线，裁决权永远在你手里——删得再快，判错了照样上线崩。
