git合并冲突不是错误，而是等待人工决策的暂停点；需用git status定位unmerged paths文件，手动编辑删去标记并验证逻辑，再git add暂存、git commit完成合并。
Git 合并冲突不是错误，是 Git 在等你做决定——它不会自动丢掉任何一方的修改，但也不会替你判断哪段逻辑该保留。只要按流程走，90% 的冲突 5 分钟内能清完。
git status 显示 Unmerged paths 怎么快速定位冲突文件
这是最直接的信号，说明合并卡在半路，Git 已把冲突文件标记为“未合并”。别扫完整个输出，盯住 Unmerged paths 下带 both modified: 的行就行。
-
git status -s | grep "^UU"是最快过滤方式，UU表示工作区和暂存区都修改过（即冲突状态） - IDE（如 VS Code）有时会缓存状态，
git status才是唯一可信来源 - 如果文件名含空格或特殊字符，用
git ls-files -u查看底层 blob hash，避免 shell 解析出错 - 别依赖
git diff默认输出——它可能只显示冲突标记，不展示上下文；加--ours或--theirs才能看到当前分支/目标分支的原始内容
手动编辑冲突文件时怎么避免删错或漏改
冲突块里三段式标记（、<code>=======、>>>>>> feature/login）不是装饰，是 Git 给你的决策边界。删标记本身不难，难的是删完后逻辑是否自洽。
- 先通读整个冲突块前后 10 行代码，确认变量作用域、函数调用链、缩进层级——尤其 Python/JSON/YAML 文件，空行和缩进错一位就运行报错
- 不要无脑保留
HEAD或feature/login全部内容；常见误操作是把两个import语句都留着，结果重复导入 - 如果两边都改了同一个函数体，优先合并逻辑（比如保留新参数 + 旧默认值），而不是选边站队
- 改完立刻用
git diff --cached <file></file>看暂存区内容，确认没多删空行、没漏掉注释、没引入语法错误
git add 之后为什么 git commit 还报错 fatal: cannot do a partial commit during a merge
这个报错只说明一件事：还有至少一个冲突文件没执行 git add。Git 不允许“部分解决”就提交，必须所有 Unmerged paths 都进暂存区。
-
git status再跑一次，重点看有没有漏掉的both modified:文件——特别是被 IDE 自动折叠、名字相似（如config.js和config.prod.js）的文件 - 别用
git add .图省事：它会把未跟踪的新文件、本不该进本次合并的改动也带上，污染提交 - 如果某个文件你确定要完全用
--theirs版本，用git checkout --theirs <file></file>后仍要git add <file></file>，否则 Git 不认 -
git commit时不加任何参数，让它弹出默认编辑器；如果硬加-m，可能跳过检查，导致提交后别人拉代码又触发冲突
什么时候该放弃手修，直接上 mergetool
手修适合单文件、1–2 处冲突；一旦出现 3 个以上文件冲突，或某个文件里有 5+ 个冲突块，mergetool 就不是“可选”，而是“必须”。眼睛比对容易串行、漏条件、误删空行。
- 配一个顺手的工具：
git config --global merge.tool vscode（VS Code）、git config --global merge.tool vimdiff（终端党）或git config --global merge.tool bc3（Beyond Compare） - 运行
git mergetool后，工具会加载 LOCAL（HEAD）、BASE（共同祖先）、REMOTE（待合并分支）三方内容，中间是可编辑的 MERGED 区域 - 在 vimdiff 中用
:diffgetbf拿左/右版本，在 VS Code 中点“Accept Current Change”或“Accept Incoming Change”——别手敲，避免复制粘贴错位 - 保存退出后，工具自动执行
git add，不用再手动确认每个文件；但记得最后仍要git commit
最容易被忽略的点是：冲突解决后没验证逻辑是否真正确——删完标记、git add、git commit 一气呵成，结果测试跑不过。建议在 git add 前，至少本地跑一遍相关模块的单元测试，或者手动触发关键路径。Git 能保证语法合法，但保不住业务逻辑。
