合并冲突的本质是：同一个文件的同一区域被两边改过，Git 无法判断该保留哪一侧，于是把决定权交回给人。处理路径通常是「先看清两侧改了什么 → 再决定保留、合并还是重做 → 最后用 git add 加提交收尾」。最忌讳的是不看内容直接 git checkout --ours . 或 --theirs . 一把梭，那样冲突标记没了，别人的改动也一起没了，而且不会有任何报错提示你。
遇到冲突先别动手改代码，按三步走：第一步用git status -s和git diff --name-only --diff-filter=U确认到底哪些文件处于未合并状态；第二步用git show :1: :2: :3:把共同祖先、当前分支、合入分支三个版本摆在一起看；第三步再编辑文件、删干净冲突标记、git add后提交。适用场景是本地 merge / rebase / cherry-pick 产生的文本冲突；二进制文件、锁文件类冲突不建议手改，应重新生成。风险边界：已推送的合并提交不要用reset --hard回滚，改用revert。验证方式是git diff --check加一次本地构建。
Git代码合并冲突先定位在哪一层
冲突看起来都是「文件里出现了一堆尖括号」，但实际可能卡在三个不同层面，改错层的代价不一样，所以先分层再动手。
第一层，工作区文件内容层。检查位置就是报冲突的那个文件本身，判断依据是文件里是否存在 <<<<<<<、=======、>>>>>>> 这样的标记段。如果有，说明 Git 已经把冲突块写进工作区，属于典型的文本冲突，直接编辑即可。如果没有标记但合并也进行不下去，说明问题不在这一层。
第二层，索引层。检查位置是 git status -s 的输出，判断依据是文件前面的状态码。UU 表示双方都改、AA 表示双方都新增、DU/UD 表示一方删除一方修改、AU/UA 同理。这几种状态码的处理方式完全不同：UU 是合并内容，DU 是决定这个文件到底留不留，不能用同一套手法。
第三层，历史层。检查位置是 git log --merge --oneline -- <文件路径>，判断依据是它能否列出冲突双方的提交。如果这一步报 fatal: bad revision 之类，通常说明当前不是一次正常的三方合并，可能是 rebase 到一半、cherry-pick 中断，或者合并基础（merge base）被压平过，这时应该先看 git status 顶部提示当前处在哪种操作中，再决定用 git merge --abort 还是 git rebase --abort 退出重来。
Git代码合并冲突：先看这四个位置
下面这段命令可以直接复制执行，用途是把四个位置一次性看全，替换项只有最后一个 path/to/file.js，换成你实际冲突的文件路径，在仓库根目录下跑。
# 位置1：命令输出——哪些文件未合并、处于什么状态
git status -s
git diff --name-only --diff-filter=U
# 位置2：日志——冲突双方各自的提交和共同祖先
git log --merge --oneline -- path/to/file.js
git show :1:path/to/file.js # 共同祖先 base
git show :2:path/to/file.js # 当前分支 ours
git show :3:path/to/file.js # 合入分支 theirs
# 位置3：配置项——冲突标记风格与换行符处理
git config --show-origin --get merge.conflictStyle
git config --show-origin --get core.autocrlf
git config --show-origin --get merge.renames
# 位置4：面板字段——网页端合并请求里的冲突提示
git remote -v # 确认对应的托管平台与仓库地址日志位置看的是 git log --merge 和 git show :1: :2: :3:，前者告诉你谁在改，后者把三方版本摊开，diff3 风格下冲突段里会多出一块 base，判断「这行原来是什么、谁改成什么」会快很多。命令输出位置看 git status -s 和 git diff --name-only --diff-filter=U，前者给状态码，后者只列未合并文件的纯路径，适合丢给脚本批量处理。配置项位置用 git config --show-origin 查，加上 --show-origin 才能看出这条配置来自全局、仓库还是某个 include 文件，避免改了全局却以为改的是当前仓库。面板字段位置指 GitHub、GitLab 这类平台的合并请求页面，通常会有 Conflicts 提示、源分支与目标分支名、以及「查看冲突文件」入口，页面上标注的冲突文件数量有时和本地不一致，原因是本地分支还没 git fetch 到最新，建议先拉一次再对照。
Git代码合并冲突：按可能性从高到低排除
按出现频率往下排，每一条都配一个能确认或排除它的动作，依次做下去通常很快能定位。
- 双方改了同一行或相邻行。确认动作：
git show :1:path/to/file.js | diff - <(git show :2:path/to/file.js)，看到改动落点交叠就属于这一类。处理是保留业务上正确的语义，必要时把两侧逻辑都留下但调整顺序。 - 格式化、缩进、换行符差异造成整段冲突。确认动作：
git diff --ignore-all-space -- path/to/file.js，如果忽略空白后差异明显变小，基本可以判定是这类。处理上优先统一编辑器与.gitattributes里的换行符策略，再重新合并，逐行手改意义不大。 - 文件被重命名或移动的同时又被修改（rename + modify）。确认动作：
git status -s里出现R相关状态，或git log --follow --oneline -- <新路径>能看到改名记录。处理是先用git mv统一路径再合并内容，不要在两个路径上各改一半。 - 二进制文件或生成物被同时改动。确认动作：
git diff --stat显示Bin，或冲突文件是图片、package-lock.json、构建产物。处理上不手改，二进制选一侧后重新导出，锁文件删除后用包管理器重新安装生成提交。 - 重复应用同一批改动导致历史错位。常见于 rebase 后又 cherry-pick。确认动作：
git log --oneline --graph --all -20看是否出现内容相同但提交号不同的两条线。处理是挑一条线保留，另一条用git rebase --abort或重建分支重来。
容易踩的坑：把冲突标记删掉、文件保存了，却忘了 git add，然后直接 git commit 报「committing is not possible because you have unmerged files」。更隐蔽的是反过来，git add 之后才发现改错了，这时文件在索引里已经是「已解决」状态，冲突标记回不来了。补救用 git checkout -m path/to/file.js 可以重新生成冲突标记，再改一遍；如果已经提交了，就在本地 git reset --soft HEAD~1 退回提交前的状态重做。
Git代码合并冲突：改完怎么确认真的解决了
不要只看「文件里没有尖括号了」就认为完成，按下面顺序验证，命令都在仓库根目录执行。
# 1. 全仓扫一遍残留的冲突标记，输出为空才干净
git grep -n -e '^<<<<<<<' -e '^=======' -e '^>>>>>>>'
# 2. 检查空白错误与残留标记
git diff --check
# 3. 确认索引里没有未合并路径（输出为空）
git diff --name-only --diff-filter=U
# 4. 本地跑构建和相关测试，再提交
git add path/to/file.js
git commit
git log --oneline -1第 1 步的 git grep 会命中代码里本来就存在的分隔线字符（例如某些 Markdown 文档），需要人工扫一眼确认不是误报。git diff --check 输出为空、--diff-filter=U 输出为空、本地构建与受影响模块的测试通过，这三项同时满足才算解决。观察多久算稳定：合并提交后在本地至少跑一次完整构建和相关测试，推到远端后看合并请求的 CI 结果，合并进主干后结合团队发布节奏观察一到两个发布周期的运行日志与错误率，具体窗口需要结合你们的发布频率确认，没有统一标准。
回滚办法按状态分三种。还没提交时，整个合并放弃用 git merge --abort，rebase 中途用 git rebase --abort；只想放弃单个文件的处理结果用 git checkout HEAD -- path/to/file.js，想保留改动但重建冲突标记用 git checkout -m path/to/file.js。已经生成本地合并提交且尚未推送，用 git reset --hard ORIG_HEAD 回到合并前。合并提交已经推送到共享分支，不要 reset，改用 git revert -m 1 <merge-commit-sha> 生成一个反向提交，-m 1 表示保留第一父提交那条主线，执行前用 git log --oneline --graph -5 确认父提交顺序，顺序判断错会把该留的分支撤掉。