git合并冲突是git主动暂停合并并交还决策权，需先用git status定位“unmerged paths”中的文件，再手动编辑删去> branch-name标记并融合逻辑，最后git add标记解决、git commit完成合并。
Git合并分支时的冲突不是失败，而是 Git 把“决策权”交还给你——只要清楚哪些操作在改什么、改到哪一行，冲突就能快速收口。
git merge 出现 conflict 后怎么定位问题文件
执行 git merge 报错后，第一反应不该是打开编辑器乱删标记，而是先看 Git 告诉你什么：
-
git status会明确列出 “Unmerged paths”，只关注这部分文件，其他文件不用管 - 每个冲突文件里，
到 <code>>>>>>> branch-name之间的块才是真冲突区，外部代码没被标记就说明 Git 已自动合并成功 - 如果一个文件里有多个冲突块，别漏掉任何一个；
git diff可以看到所有差异，但不如git status直观
手动编辑冲突文件时最容易踩的坑
删标记本身不难，难的是删完之后代码是否还能跑。常见翻车点：
- 只删了
和 <code>>>>>>>，忘了删中间的=======，导致语法错误 - 保留了两段逻辑都写死的变量赋值，比如重复定义
const API_URL = 'v1'和const API_URL = 'v2'，没合并或重命名 - 删掉了别人加的 import 或函数调用，自己只留了业务逻辑，结果编译报
ReferenceError - 冲突块跨多行 if/else 或对象字面量时，缩进或括号不匹配，肉眼难发现
什么时候该用 git checkout --ours 或 --theirs
这两个命令不是“偷懒捷径”，而是有明确适用场景的覆盖策略：
-
git checkout --ours <file></file>：当前分支（HEAD）的修改是权威版本，比如你在main上修复了一个安全漏洞，现在要把feature合进来，但其中某配置文件被误改，就该强用--ours -
git checkout --theirs <file></file>：待合并分支的改动才是目标，比如你本地dev分支只是临时调试加了 console.log，而staging分支的同文件已清理干净，那就用--theirs - 注意：
--ours/--theirs是按文件粒度操作，不能只对部分代码生效；且仅在git merge过程中有效，git rebase里语义相反
用 git mergetool 之前必须配好的三件事
很多人配了 git mergetool 却卡在启动失败，往往是因为漏了底层依赖：
- 先确认工具本身可运行：比如 VS Code 要能通过终端输入
code --version正常返回，否则git config --global merge.tool vscode白配 - 设置
mergetool.vscode.cmd，否则 Git 不知道怎么传参。正确示例：git config --global mergetool.vscode.cmd 'code --wait --merge $LOCAL $REMOTE $BASE $MERGED' - 三方合并工具依赖
$BASE（共同祖先）、$LOCAL（当前分支）、$REMOTE（待合并分支）三个快照，缺一不可；如果某次合并是快进（fast-forward），git mergetool可能不触发
冲突标记不是障碍物，是 Git 给你画出的“责任边界”——它清楚告诉你：这一段，只有你能决定怎么写。越早看清这个逻辑，就越少在 git add 之后才发现 import 漏了、括号没闭合、类型定义冲突了。
