Git合并冲突需手动解决：先用git status定位Unmerged paths文件，编辑删除 branch-name标记，保留合法代码并git add暂存，最后git commit完成合并。
Git 合并冲突不是错误，是 Git 在等你做决定——不手动编辑、不 git add，merge 就永远卡在中间状态。
看到 CONFLICT (content) 和文件里出现 怎么办
这是最典型的文本冲突标记，说明 Git 发现同一段代码在两个分支里被改了不同内容。它不会自动猜你要留哪边，而是把三方内容（共同祖先、当前分支、待合并分支）用分隔符包起来，等你删掉标记、留下最终版本。
到=======之间是当前分支（git checkout --ours对应的内容）-
=======到>>>>> branch-name是待合并分支（git checkout --theirs对应的内容） - 必须手动删掉这三行标记，只保留合法、可运行的代码；空行、缩进、JSON 逗号都得对上，否则后续
git commit会失败 - 别用
git checkout --ours或--theirs批量覆盖——它们跳过逻辑比对，容易把关键修复或新字段直接干掉
git status 显示 Unmerged paths 但找不到冲突文件
说明 Git 已识别出冲突，但某些文件可能被 IDE 自动“清理”了标记（比如 VS Code 的保存钩子），或者你误删了部分冲突块导致 Git 无法准确定位。这时不能靠肉眼扫，得用命令确认真实状态。
- 运行
git status --short，看输出里带UU标记的文件（Unmerged Untracked），这才是真冲突文件 - 用
git diff --name-only --diff-filter=U也能列出所有未解决冲突的文件 - 如果某个文件在
git status里没显示但实际有修改，可能是你提前git add过又改了——先git restore --staged把暂存区还原，再重新检查 - 注意：Windows 上换行符（CRLF vs LF）差异有时会触发假冲突，可用
git config core.autocrlf true统一处理
用 git mergetool 比纯文本编辑快在哪
当冲突文件超过 3 个，或涉及 JSON/YAML/Python 等格式敏感文件时，图形化工具能显著降低看串行、漏空格、误删注释的风险。它不是“偷懒”，而是把 Git 的三方合并逻辑可视化。
- 先配一个可用工具：
git config --global merge.tool vscode（或vimdiff、meld） - 运行
git mergetool，它会依次打开每个冲突文件，左边是 LOCAL（当前分支）、中间是 BASE（共同祖先）、右边是 REMOTE（待合并分支），底部是 MERGED 编辑区 - 工具保存退出后，自动执行
git add，不用再一个个敲命令 - 如果某次只有一两个冲突，手修更快；但一旦涉及嵌套对象、条件分支合并，mergetool 的左右对比能立刻暴露逻辑断层
冲突解决完 git commit 提交失败或 push 被拒
常见原因是：没对所有冲突文件执行 git add，或者远程分支已有新提交。Git 不会让你带着未解决状态继续，但也不会主动告诉你漏了哪个文件。
- 再次运行
git status，确认所有冲突文件都从Unmerged paths移到了Changes to be committed - 如果
git commit报错 “nothing to commit”，说明还有文件没git add，或者你git add .时漏掉了未跟踪的新文件 - push 被拒大概率是远程分支更新了，此时不要
git push --force，先git pull --rebase拉取最新再重试 - 万一合完发现逻辑错了，用
git revert -m 1回退，-m 1是关键，否则 revert 会当成普通提交处理
真正容易被忽略的是：冲突解决不是“删掉标记就完事”，而是要验证行为是否符合预期——比如两个分支都加了同一个 API 调用，你保留了一个，但忘了改参数名，测试时才会暴露。每次解决完，至少跑一次相关单元测试或手动触发关键路径。
