看到 conflict (content) 应立即停止操作，先用 git status 定位冲突文件，手动清除冲突标记（）并保留最终代码，再逐个 git add ，最后 git commit 完成合并。
看到 CONFLICT (content) 就该停手，别急着 git add .
Git 检测到同一文件的同一段落被两个分支各自修改，就会中止合并并报出 CONFLICT (content): Merge conflict in <filename></filename>。这不是错误，而是 Git 在说：“这段我没法替你决定，得你来拍板”。此时工作区已处于“未完成合并”状态，git status 会显示 both modified 的文件，且这些文件里塞满了冲突标记。
- 别一上来就
git add .—— 这会把带冲突标记的“半成品”一起暂存，后续提交反而更难回退 - 先用
git status锁定具体哪些文件冲突，只打开它们，其他文件不用碰 - 冲突标记长这样：
（当前分支内容）、<code>=======（分隔线）、>>>>>> branch-a（待合并分支内容）—— 三者必须**全部手动删掉**，只留下你确认保留或整合后的最终代码 - 改完一个文件后，立刻
git add <filename></filename>，Git 才会把它从“未解决”列表里划掉
用 git mergetool 比纯手改快得多，但得先配好工具
图形化合并工具（比如 meld、bcompare、VS Code 内置的合并视图）能直观对比三方：BASE（共同祖先）、LOCAL（当前分支）、REMOTE（待合入分支），避免看花眼漏删标记。但它不会自动启动，得自己配。
- 配一次就能长期用：
git config --global merge.tool meld（换成vscode或bcompare也行） - 启动命令就是
git mergetool，它会逐个打开冲突文件，选好再保存退出即可 - 注意：如果没配
merge.tool直接运行git mergetool，Git 会弹一堆提示问你用哪个工具，容易卡住 - VS Code 用户可跳过配置，直接在冲突文件里点右上角“接受当前更改/接受传入更改/接受两者”，但记得最后仍要
git add手动标记解决
git merge --abort 是安全网，但只在合并中途有效
改了一半发现理不清逻辑？或者误删了不该删的代码？别硬撑，git merge --abort 能退回合并前的状态——前提是还没执行 git commit。
- 一旦你已经
git commit了冲突解决结果，--abort就失效了，只能靠git reset --hard ORIG_HEAD（如果没覆盖过）或翻日志找前一个 commit - 执行
git merge --abort后，所有未add的修改都会恢复原样，已add的冲突文件也会还原成合并前内容 - 警告：如果合并开始前本地就有未提交改动，
--abort可能无法完全复原——所以养成“合并前先git status确认干净”的习惯
解决完别忘 git commit，否则合并没真正完成
很多人以为删完冲突标记、git add 完就结束了，其实 Git 还等着你敲下最后一句 git commit。此时不写 -m 参数，Git 会自动弹出编辑器让你填提交信息——这是强制提醒你：这不是普通提交，是合并提交。
- 提交信息建议写清楚来源，比如：
git commit -m "Merge branch 'feature/login' into develop, resolve conflict in auth.js" - 如果用了
--no-commit启动合并（例如想检查后再提交），那git commit就是必选项，跳过它等于没合并 - 推送前务必
git status确认输出是 “nothing to commit, working tree clean”——只要还剩一个unmerged paths，远程仓库就拒绝你的 push
真正麻烦的不是冲突本身，而是改完没测试、提交没推、或者多人同时解决同一处却没同步方案。留个心眼：改完冲突，哪怕只是加个 console.log，也顺手跑一下相关功能。
