git冲突是主动暂停合并待人工决策，非错误；需用git status定位unmerged paths文件，git diff分析差异，手动编辑删标记并融合逻辑，再git add标记解决，最后git commit完成合并。
冲突不是 Git 报错，是它主动暂停合并、等你拍板——只要不删文件、不乱 git reset --hard，就没人丢代码。
看到 CONFLICT (content) 别慌，先用 git status 定位文件
Git 会卡在合并中途，git status 输出里出现 Unmerged paths 就是明确信号。这时候工作区文件里会有三段标记：、<code>=======、>>>>>> branch-name。别跳过这步直接开编辑——很多误操作源于没确认到底哪几个文件真冲突了。
-
git diff看整体差异；想单独看当前分支改了啥，用git diff --ours <file></file>；看对方分支改了啥，用git diff --theirs <file></file> - 如果文件名带空格或特殊字符，
git status输出里会用引号包住，复制时注意别漏掉 - 某些 IDE（如 VS Code）会在侧边栏高亮冲突文件，但别全信——它可能漏掉二进制文件或 submodule 冲突
手动编辑时，删标记只是第一步，逻辑融合才是关键
删掉 、<code>=======、>>>>>> 这三行只是清理动作，真正要决定的是：这两段代码要不要都留？参数要不要合并？if 条件要不要重写？尤其在 JSON/YAML/Python 缩进敏感场景，少个空格或换行都可能让文件失效。
- 函数签名冲突（比如同一函数被两分支分别加了参数），不能只留一边——得手动合并参数列表和调用逻辑
- 删除文件 + 修改同名文件会触发
CONFLICT (modify/delete)，这时得判断：是要保留删除，还是保留修改，还是恢复文件再改 - 别依赖
git checkout --ours或git checkout --theirs一键覆盖——它们在rebase中含义翻转，且不处理跨行逻辑耦合
解决完必须 git add，否则 Git 永远认为“还没好”
git add 不是走形式，是向 Git 明确声明：“这个文件的冲突我已人工审过，现在内容可靠”。漏掉任一冲突文件，git commit 都会被拦住，且 git status 仍显示 Unmerged paths。
- 逐个
git add <file></file>，别偷懒用git add .——它会把未解决的文件也塞进去，导致提交失败 - 加完后
git status应该只显示Changes to be committed，没有Unmerged paths - 如果用了
git mergetool，工具退出时通常自动执行git add，但建议仍跑一次git status确认
提交后发现逻辑错了，优先 git revert -m 1 而不是 git push --force
合并提交是“两个父提交”的特殊节点，直接 push --force 会重写历史，协作成员 fetch 后可能出现重复提交、reflog 错乱甚至本地分支失联。 revert 是安全的反向操作，生成新提交抵消前次合并，所有人均可无感同步。
- 查合并提交哈希：
git log --oneline --graph | grep 'Merge' - 执行：
git revert -m 1 <merge-commit-hash></merge-commit-hash>（-m 1表示以第一个父提交为基准回退） - 如果已经推送到远程，revert 后照常
git push，无需 force
最易被忽略的一点：冲突解决过程本身不校验语法或运行逻辑，git add 和 git commit 成功 ≠ 代码能跑。改完务必本地跑一遍单元测试或至少执行下关键路径，否则把 bug 合并进主干，代价远高于多花两分钟验证。
