Git分支冲突不是故障，而是Git在等待你手动决定保留哪部分逻辑；它已将双方修改保留在工作区，只需通过git status定位冲突文件、编辑标记块、git add暂存并git commit完成合并。
Git分支冲突不是故障，是 Git 在等你做决定——它已经把双方修改都保留在工作区里，只差你手动确认保留哪部分逻辑。
看到 CONFLICT (content) 时先别 panic，立刻 run git status
错误现象：终端报 CONFLICT (content): Merge conflict in src/utils/api.ts，但你不确定改了哪些文件。
git status 是唯一可信入口，输出中 “Unmerged paths” 下列出的每一行，就是真实卡住的文件。
不要依赖 IDE 状态栏——旧版 VS Code 或 WebStorm 在暂存区混乱时可能漏标，git status 才是事实来源。
如果输出里还带 “both modified”，说明该文件在两个分支里都被改过；如果是 “deleted by them”，说明对方删了这个文件而你改了它——这种类型容易引发环境不一致，要特别留意。
编辑冲突文件时，别只删 <<<<<< 和 >>>>>> 标记
冲突块长这样：
console.log('fetch user');
<<<<<< HEAD
const token = localStorage.getItem('auth');
======
const token = sessionStorage.getItem('auth');
>>>>>> feature-auth
删标记只是第一步，关键在三件事：
- 确认
<<<<<< HEAD上方是你当前分支（比如feature-login）的代码，下方是待合并分支（比如main）的代码 - 不能只删分隔符、留两段代码——语法会错，逻辑可能重复调用
- 如果某段逻辑其实已废弃（比如用
localStorage存 token 已被团队弃用），要连同整块代码一起删，而不是只留“干净”的那一段
改完保存后，必须对每个文件单独执行 git add src/utils/api.ts。没 git add，Git 仍认为它处于冲突状态，git commit 会被拒绝。
git checkout --ours 和 git checkout --theirs 的真实行为
这两个命令不是“选 A 或 B”那么简单，它们的含义取决于上下文：
- 在
git merge过程中：--ours指当前所在分支（HEAD），--theirs指你正合并进来的那个分支 - 但在
git rebase中，含义完全翻转：--ours反而是“对方分支”的内容，--theirs是你自己的提交——这点极易踩坑 - 它们只影响工作区和暂存区，不移动 HEAD，也不是撤销合并的方式
适用场景有限：比如你确定要完全丢弃对方分支对某个配置文件的改动，就用 git checkout --theirs package.json，再 git add package.json。但对业务逻辑文件，盲目用这个命令大概率引入 bug。
超过 3 个冲突文件，别硬扛，直接上 git mergetool
纯靠眼睛扫 <<<<<< 块，在 JSON/YAML/Python 这类缩进或结构敏感的文件里，极容易看串行、漏空行、误删条件分支。
先配一个靠谱工具：git config --global merge.tool vscode（或 vimdiff、meld），然后运行 git mergetool。
工具会并排显示三方内容：LOCAL（你当前分支）、BASE（共同祖先）、REMOTE（对方分支），中间是 MERGED 区域供你编辑。
保存退出后，它自动帮你 git add，不用再一个个确认。
注意：如果只有 1–2 个文件冲突，手修更快；但一旦超过 5 个，mergetool 节省的时间远超配置成本。
最常被忽略的一点：冲突解决后，git commit 生成的是一个合并提交，它的父提交有两个。如果你后续发现逻辑错了，优先用 git revert -m 1 <merge-commit-hash> 回退，而不是 git push --force——后者会破坏他人本地历史，尤其在共享分支上风险极高。
