Git合并冲突是Git明确提示需人工决策，非系统错误；看到CONFLICT提示后应先git status查看冲突文件，手动编辑删除<<<<<<<、=======、>>>>>>>标记并保留所需内容，再git add标记解决，最后git commit完成合并。
Git 合并冲突不是 Git 出错了，而是它明确告诉你：「这两段修改我没法自动选一个，得你来定」。只要理解冲突标记含义、操作顺序和关键命令边界，90% 的冲突 5 分钟内就能干净解决。
看到 CONFLICT (content) 提示后该做什么
执行 git merge 或 git pull 后出现这行，说明 Git 已停在合并中途，工作区文件已被写入冲突标记，但尚未提交。此时不能直接 git commit，也不能强行 git push。
- 先运行
git status，它会列出所有冲突文件（状态显示为both modified） - 打开任一冲突文件，你会看到类似这样的三段结构：
<<<<<< HEAD // 当前分支（如 master）的代码 ======= // 要合并进来的分支（如 feature/login）的代码 >>>>>> feature/login
- 手动删掉
<<<<<<、=======、>>>>>>这三行，只保留你最终需要的逻辑——可以全留 A、全留 B、或拼接两者 - 保存文件，然后
git add <文件名>标记为已解决（不是git commit）
用 git mergetool 替代手敲标记
当冲突文件多、或涉及复杂逻辑（比如 JSON 配置、HTML 模板嵌套），纯文本编辑容易漏删标记或误删代码。这时图形化工具更稳。
- 确保已配置好工具，例如：
git config --global merge.tool vimdiff（Linux/macOS）或git config --global merge.tool bc3（Windows + Beyond Compare） - 运行
git mergetool，它会逐个打开冲突文件，在左右/上下/基线三栏中高亮差异 - 在工具里选择「Accept Current Change」「Accept Incoming Change」或手动编辑，保存即完成该文件解决
- 退出工具后，Git 自动执行
git add，你只需最后git commit - 注意：
git mergetool不会跳过已解决的文件，如果中途退出，下次再运行会从第一个未解决的继续
git merge --abort 是安全撤退键
改到一半发现逻辑全乱了，或者误删了不该删的代码？别硬撑。Git 允许你在任何阶段干净回退。
- 只要还没运行
git commit，就仍处于MERGING状态，此时git merge --abort会立即还原到 merge 前的 HEAD，所有冲突标记、未暂存修改全部清除 - 它等价于撤销整个 merge 操作，但不会动你本地其他分支或已提交的历史
- 常见误操作：先
git add再想 abort → 失败，因为git merge --abort要求暂存区为空；此时得先git reset再 abort - abort 后可重新
git pull origin main拉最新主干，再试 merge，或换思路 rebase
为什么 git checkout --ours 和 --theirs 容易翻车
这两个参数看似能一键取舍，但语义极易被误解——它们的「ours/theirs」取决于你当前在哪分支执行 merge，而不是你直觉里的「我的/别人的」。
- 假设你在
main分支上运行git merge feature： •git checkout --ours <file>→ 保留main分支版本（即「当前分支」） •git checkout --theirs <file>→ 保留feature分支版本（即「传入分支」） - 但如果反过来，在
feature上 mergemain，含义就对调了 - 更大的坑：这些命令只作用于工作区，不会自动
git add；且对有多个祖先的合并（如 octopus merge）行为不可控 - 建议仅用于确认无逻辑差异的纯覆盖场景（如更新第三方库 lock 文件），否则优先手动编辑或用 mergetool
真正卡住人的往往不是冲突本身，而是混淆了「当前分支」「传入分支」「已暂存」「未暂存」这几个状态边界。每次操作前看一眼 git status，比死记命令管用得多。
