快速定位冲突文件的唯一可靠命令是git status，查看其输出中“Unmerged paths”下的文件列表，如“both modified: src/utils/date.ts”，每一行均为需处理的冲突文件。
git pull 触发 conflict (content) 怎么快速定位冲突文件
Git 报错里不会直接列出所有冲突文件，它只告诉你「合并失败」。真正能立刻锁定问题的命令只有一个：git status。
执行后看输出中 Unmerged paths 下的内容，比如：
Unmerged paths:
(use "git add <file>" to mark resolution)
both modified: src/utils/date.ts
deleted by them: package-lock.json
每一行都是真实卡住的文件，both modified 是最常见类型，deleted by them 或 added by them 表示文件被对方删/加，而你改了同名文件——这种容易漏看，但同样必须处理。
- 别依赖 IDE 右下角状态或 Git 图形界面，VS Code 旧版本在暂存区混乱时可能不标冲突文件
-
git ls-files -u能看到 stage 1/2/3 的 blob，适合写脚本批量检查，日常没必要 - 如果
git status没显示 Unmerged paths，说明根本没进入冲突状态，可能是网络错误或权限问题，不是冲突
手动编辑冲突标记时哪些操作会埋雷
冲突块里的 <<<<<< HEAD、=======、>>>>>> origin/main 不是装饰，是 Git 给你划的决策线。删标记本身不危险，危险的是删得不干净。
- 不能只删三行标记，留下两段代码——哪怕逻辑上不重复，也可能造成语法错误（比如删了
}或;） - 如果某段代码其实已被废弃（比如调用了一个已下线的 API），要整块删掉，而不是只留标记内“看着干净”的部分
- 改完后必须对每个文件单独执行
git add <file>；只保存文件、不git add，Git 仍认为该文件处于冲突状态，git commit会被拒绝 - 二进制文件（如图片、PDF）不会出现文本标记，
git status显示both modified就得靠人工比对内容，或用外部 diff 工具
git pull --rebase 和 git merge 冲突解决步骤一样，但意图完全不同
表面上都是找标记 → 编辑 → git add → 继续，但背后逻辑差一个维度。
git merge 是把两个分支「并在一起」，你保留的是双方共存的结果；git rebase 是把你自己的提交「重放」到别人的新基线上，每次解决的其实是「这个提交在新上下文里是否还成立」。
- rebase 过程中遇到冲突，
git add <file>后必须用git rebase --continue，不是git commit - 如果中途想放弃，
git rebase --abort会回到 rebase 前状态；git merge --abort对应 merge 场景 - rebase 后的提交哈希全变了，所以推送到远程要用
git push --force-with-lease origin <branch>，不能直接git push - 团队协作中，不要对已推送的提交做 rebase，尤其别 rebase 公共分支（如
main）上的历史
git push 被拒后直接 git reset --hard HEAD~1 很危险
很多人看到 push 被拒，第一反应是“回退本地提交”，但这是典型误操作。push 被拒的根本原因是「你的本地分支落后于远程」，不是你本地多了什么。
执行 git reset --hard HEAD~1 会直接丢掉你最新的提交，连带里面的所有修改——哪怕那些代码完全没问题、也没和别人冲突。
- 正确做法是先
git fetch origin，再git merge origin/<branch>或git rebase origin/<branch> - 如果真想撤回未推送的提交，用
git reset --soft HEAD~1更安全：保留工作区和暂存区，只是撤销提交动作 - 已经
git push过的提交，想清理只能靠git revert <commit-id>，生成反向提交，不破坏历史线性
冲突不是 Git 在刁难你，是它在等你确认哪段逻辑该活下来。标记删得再快，不如先看清 HEAD 和 incoming 分别代表谁的上下文——这点一旦模糊，后面每一步都可能翻车。
