Git冲突需手动解决：一、编辑冲突文件删标记后提交；二、用git checkout --ours/theirs选版本；三、配merge.tool可视化合并；四、用git merge --abort中止合并。
手动处理 Git 合并冲突不是“出错了”，而是 Git 在告诉你：这两处修改逻辑上无法自动取舍，需要你来拍板。只要理解标记含义、操作顺序清晰、不跳过 git add 这一步，90% 的冲突都能 2 分钟内解决。
看到
Git 插入的冲突标记不是装饰，是明确的信号：文件已进入“未合并”状态，此时任何 git commit 都会失败，强行提交会把标记一起塞进历史里。常见错误包括：
- 直接
git commit而没先git add冲突文件 - 只删了
>>>>>> branch-name却漏掉=======，导致语法错误 - 用 IDE “一键接受当前”但没验证上下文，比如删掉了关键的 import 或闭合标签
打开冲突文件后，你会看到三段结构：
<<<<<< HEAD // 当前分支（如 master）的代码 ======= // 待合并分支（如 feature/login）的代码 >>>>>> feature/login
必须手动删掉这三行标记，并保留或融合中间的内容——不能只留一半。
git status 是冲突处理的起点和终点
它不只告诉你哪些文件冲突，还提示下一步该做什么。执行 git status 后你会看到类似：
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: src/utils/date.js
这意味着：date.js 是唯一需要你动手的文件，其他文件 Git 已自动合并成功。重点就在这里：
- 不要凭感觉去翻所有改动过的文件，只处理
git status明确列出的both modified或unmerged条目 - 解决一个文件后，立刻
git add src/utils/date.js，它会从Unmerged paths列表中消失 - 当
git status不再显示Unmerged paths，只剩Changes to be committed时，才能git commit
merge 和 rebase 冲突的处理动作完全一样
很多人以为 git merge 和 git rebase 冲突要不同对待，其实不然。区别只在触发时机：
-
git merge feature冲突：你在目标分支（如main）上，想把feature合进来 -
git rebase main冲突：你在feature分支上，想把main的新提交“重放”到自己头上
但冲突发生后的操作链一模一样：
编辑文件 → 删除冲突标记 → git add 文件 → git merge --continue（或 git rebase --continue）
注意：git merge --continue 和 git rebase --continue 是收尾命令，不是可选项；不运行它们，Git 会一直卡在“合并进行中”状态，后续任何操作都可能报错。
AI 生成代码带来的特殊陷阱
2026 年大量冲突来自 Copilot、Cursor 等工具生成的相似但不一致的代码，比如：
- 同一功能，一边生成
const formatDate = (d) => d.toISOString().split('T')[0];，另一边是function formatDate(date) { return date.toISOString().substring(0, 10); } - 变量名风格混用：
userInputvsinputValue，IDE 自动补全时容易忽略差异 - 注释块位置不同，导致冲突标记夹在函数中间，删错一行就破坏逻辑
这种冲突不能靠“选左边/右边”速决。建议打开两个版本的原始提交（git show HEAD:src/file.js 和 git show feature/file.js），对比真实意图，再手工重写一段干净实现——比缝合两段 AI 代码更可靠。
最常被跳过的环节是：解决完所有冲突后，没跑一遍本地测试就直接 git commit。尤其当冲突涉及函数签名或数据结构变更时，编译通过不等于逻辑正确。
