先运行git status，它会明确列出unmerged paths下的冲突文件；若仅一行显示“both modified: xxx”，即为单文件冲突，但需注意空格、换行等隐性变更也可能触发额外冲突。
怎么快速定位冲突文件并确认是否只有单个文件
执行 git merge 或 git pull 报错后，第一反应不是打开编辑器，而是先运行 git status。它会明确列出所有状态为 Unmerged paths 的文件——如果只有一行显示类似 both modified: src/utils.js，那确实是单文件冲突。
注意：别跳过这步。有时候你以为只改了一个文件，但 git status 会暴露出被自动换行、缩进或 BOM 影响的其他文件（比如 package.json 因空格变化也被标为冲突）。
- 用
git ls-files --unmerged可以更干净地只看真正有三路合并状态的文件（HEAD、base、other） - 如果输出为空，说明没真冲突，可能是暂存区混乱，试试
git reset --mixed
冲突标记里 >>>>>> 是什么含义
Git 插入的这三段标记不是装饰，是严格按合并逻辑生成的：
后面是「你当前所在分支」的最新提交内容（即目标分支，比如 <code>main）-
=======是分隔线 -
>>>>>> branch-name后面是「正被合并进来那个分支」的对应提交内容（比如feature/login）
关键点：HEAD 不代表“你的修改”，而是代表你 checkout 的那个分支的最新快照。如果你在 feature 分支上执行 git merge main，那 HEAD 就指 feature 的内容，branch-name 才是 main —— 很多人在这里看反了，导致删错代码。
Cnb Cool Git
下载
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
手动编辑时必须删掉的三行标记和常见误操作
编辑冲突文件时，这三行必须全部删除：、<code>=======、>>>>>> branch-name。漏删任意一行，git add 后仍会被视为未解决。
- 不要只删中间的
=======，上下两行也得清干净 - 不要用 IDE 的「自动折叠」功能隐藏标记区域——折叠后容易误以为已删完，实际只是看不见
- 如果文件里出现多处冲突（比如函数体 + 注释各一处），每处都得独立处理，不能只修第一个
- 改完保存后，用
git diff --staged src/utils.js确认暂存区内容是否干净（输出应为空）
修复完为什么 git add 之后还要 git commit
因为 git merge 是一个未完成的操作，冲突解决只是中间步骤。执行 git add 只是告诉 Git “这个文件我搞定了”，但整个合并动作还没落库。
- 必须运行
git commit（不加-m会弹出默认编辑器，保留预设的 Merge message 即可） - 不能用
git commit -a，它会跳过未跟踪文件，且可能误提交其他改动 - 如果中途想放弃，用
git merge --abort，它会撤回到 merge 前状态，比手动git reset安全
单文件冲突看似简单，但最容易卡在「删了标记却忘了 commit」或者「HEAD 和 branch-name 看反导致逻辑覆盖错误」——这两处没有提示，只能靠自己核对清楚。
