遇到 Git 拉取代码冲突，先不要急着手动改文件。先判断当前处在哪一种状态：是 git pull 已经报出 CONFLICT (content) 并停下，还是 pull 直接被拒绝、提示本地有未提交改动或分支分叉。前者需要解决冲突后提交，后者通常要先处理本地改动或选择 merge/rebase 方式，两者的处理路径不同。
Git 拉取冲突的核心判断是：git status里是否出现 “Unmerged paths” 和 “both modified”。出现，说明已经进入合并冲突状态，需编辑冲突文件、git add后提交；没出现而只是 “Your local changes would be overwritten”，说明拉取尚未开始，应先 stash 或提交本地改动再拉。解决后用git status确认无未合并路径、git diff检查标记清除，并在本地跑一次构建或测试再推送。不确定时优先保留可回退点，不要直接git reset --hard。
拉取代码冲突：先把能核对的事实摆清楚
先确认三件事，不要凭感觉判断。第一，当前分支和远端分支：
git branch -vv
git remote -v输出里能看到本地分支跟踪的是哪个远端分支，例如 origin/main，以及本地是否领先或落后。第二，工作区状态：
git status需要核对的字段是：是否存在 “Changes not staged for commit”（未暂存改动）、“Unmerged paths”（未合并路径）、“both modified”（双方都修改）。第三，最近提交历史，用于判断分叉点：
git log --oneline --graph --decorate -n 20如果图里出现两条线在本地分叉，说明本地提交和远端提交已经分开。此时 git pull 的默认行为取决于 pull.rebase 配置，可以先查：
git config --get pull.rebase没有输出表示未设置，具体合并方式要结合 Git 版本和团队约定确认。日志和状态都在本地终端输出，不需要去翻某个面板；如果使用 GitLab、GitHub 的网页端，合并请求页面也会显示冲突文件列表，可作为对照。
拉取代码冲突最容易搞错的一点
最常见的误解是：把“拉取被拒绝”当成“已经冲突了”，于是直接去文件里找 <<<<<<< 标记。实际上，如果 git pull 提示 error: Your local changes to the following files would be overwritten by merge，说明 Git 在拉取前就停下了，工作区里根本没有冲突标记，需要先处理本地改动。
区分这两种情况的检查动作很简单，执行一次：
git status --short看输出前缀：UU、AA、DU 等双字母状态表示已进入未合并状态，属于真冲突；如果只是 M（前面空格、后面 M）表示文件被修改但未暂存，属于拉取前的本地改动。两种情况处理顺序不同：前者编辑冲突文件，后者先 git stash 或提交再拉。
拉取代码冲突：一个照着就能做完的做法
以下路径适用于已经出现真冲突、git status 显示 “Unmerged paths” 的情况。先留一个可回退点：
git stash list
git rev-parse HEAD记下当前 HEAD 的提交号，必要时可以回退。然后查看冲突文件：
git diff --name-only --diff-filter=U这个命令只列出未合并的文件。逐个打开，会看到类似结构：
<<<<<<< HEAD
本地分支的内容
=======
远端分支的内容
>>>>>>> origin/main根据业务逻辑决定保留哪边、还是合并两边，然后删除 <<<<<<<、=======、>>>>>>> 这三行标记。每处理完一个文件就暂存：
git add 冲突文件路径全部处理完后，git status 应该不再显示 “Unmerged paths”，而是显示 “All conflicts fixed but you are still merging”。此时完成合并提交：
git commit如果不想保留默认的合并提交信息，可以改成 git commit -m "merge: 解决拉取冲突"。如果团队使用 rebase 方式拉取，流程是 git pull --rebase 后逐个 git add，再执行 git rebase --continue；中途想放弃用 git rebase --abort 回到拉取前状态。选 merge 还是 rebase，需要结合团队提交规范确认，不要凭习惯切换。
拉取代码冲突：怎么验证结果对不对
解决冲突后不要立刻推送，先做三项核对。第一，状态干净：
git status正常结果应显示 “nothing to commit, working tree clean”，且不再出现 “Unmerged paths”。第二，冲突标记已清除：
git diff --check如果还有残留的冲突标记或空白错误，这个命令会列出行号；没有输出表示通过。也可以直接搜索文件：
git grep -n "<<<<<<<\|=======\|>>>>>>>"正常情况下不应命中任何结果。第三，内容是否符合预期：
git log --oneline --graph -n 10合并提交应该出现在图上，父提交同时指向本地和远端两条线。最后在本地跑一次构建或测试命令（具体命令取决于项目，例如 npm test、mvn test），确认冲突解决没有破坏代码逻辑，再执行 git push。推送后在远端仓库的提交记录或合并请求页面确认这次提交已经出现，才算闭环。