git status是唯一可靠入口，它明确列出Unmerged paths下的both modified、deleted by us、added by them三类冲突文件，而非仅显示普通修改。
Git merge 时出现冲突不是失败，而是它在等你做决定——只要知道标记怎么读、文件怎么改、命令怎么走，5 分钟就能收工。
怎么看哪些文件真的冲突了
别凭感觉翻代码，git status 是唯一可靠入口。它会把冲突文件标为 Unmerged paths，并分三类列出：
-
both modified：两边都改了同一文件（最常见） -
deleted by us：你在当前分支删了，对方改了 -
added by them：对方新增了文件，而你本地没这个文件但有同名未跟踪项
注意：git status 不会告诉你哪一行冲突，只告诉你“有冲突”，具体位置得打开文件看标记。
怎么读懂>>>>>>分支名
冲突块长这样：
function formatPrice(price) {
<<<<<< HEAD
return '￥' + Number(price).toFixed(2);
=======
return '$' + Number(price).toFixed(2);
>>>>>> feature/pay-v2
}
其中：
-
<<<<<< HEAD下面是**你当前所在分支**（比如main）的修改 -
=======是分隔线 -
>>>>>> feature/pay-v2上面是**待合并分支**的修改
关键点：HEAD 不代表“最新版”，只代表你 git checkout 进去的那个分支。如果误以为 HEAD 一定是主干，就容易选错版本。
解决后为什么 git add 不能跳过
git add <file> 不是“提交”，而是告诉 Git：“这个文件的冲突我已手动处理完毕，你可以把它从冲突状态里移出去”。漏掉这步，git commit 会直接报错：
fatal: cannot do a partial commit during a merge.
常见错误操作：
- 改完代码，直接
git commit—— 报错，因为 Git 还在“合并中”状态 - 用
git add .全部添加 —— 可能误加未解决的其他冲突文件，导致提交不干净 - 只
git add了部分冲突文件 —— 剩下的仍卡在合并流程里，git status依然显示冲突
建议：逐个 git add <file>，每加一个就 git status 确认一次，直到所有冲突文件都不再出现在 Unmerged paths 区域。
要不要用 git mergetool
图形化工具（如 kdiff3、vscode）适合三种情况：
- 冲突文件多（>3 个）、且每个文件都有多处冲突
- 你不确定两段逻辑是否可以融合，需要并排对比上下文
- 团队统一配置了
mergetool，评审或交接时需留痕
但它不是银弹：
- 首次配置麻烦（要设
git config --global merge.tool和路径） - 某些工具会自动写入临时文件，关掉前忘记保存就白忙
- 纯文本小冲突（比如改个字符串），开 GUI 反而慢于手动删标记
真实经验：日常单文件单处冲突，手改 + git add 最快；批量或复杂逻辑冲突，再启动 git mergetool。
最常被忽略的一点：冲突解决后，git commit 的默认消息是 Merge branch 'xxx'，但如果你合并的是带业务语义的分支（比如 feature/refund-logic），最好手动加一句说明，比如 -m "Merge feature/refund-logic: resolve price format conflict"——下次 git blame 或回溯时，你会感谢现在的自己。
