git合并冲突本质是分支在相同文件相同位置有不同修改，git主动暂停让开发者决策，属协作必经的对齐环节，并非错误。常见原因包括本地分支长期未同步主干、多人修改同一行、函数重命名/删除与主干引用不一致、或变基冲突未清理就执行merge。
主干（如 main 或 develop）合并到个人分支时冲突，本质是你的本地分支和上游主干在相同文件、相同位置做了不同修改——Git 不知道该留谁的，所以停住让你决定。这不是错误，而是协作中必经的“对齐环节”。
为什么 git merge main 到个人分支会冲突，而别人没遇到？
常见原因不是代码写得差，而是时间差和操作习惯：
- 你很久没从
main拉最新代码，本地分支已偏离主干多轮提交； - 你改了某个工具配置、日志语句或接口字段，而
main上同一行刚被 CI 脚本或另一位同学更新过； - 你在个人分支里重命名/删了某个函数，但
main上它还在被其他 PR 引用——Git 无法自动判断“这是重构还是误删”； - 你用了
git pull --rebase但中途没处理完变基冲突，又切回原分支执行merge，导致冲突叠加。
别手动删
看到冲突文件里一堆 和 <code>>>>>>> main，第一反应不是删标记，而是确认：这真的是逻辑冲突，还是 Git 把“只是格式差异”也当冲突了？
- 先运行
git status，只关注标为Unmerged paths的文件，忽略both modified但没标冲突的——那些可能只是需git add； - 用
git diff --ours <file></file>看你本地分支的版本，git diff --theirs <file></file>看main上的内容，比直接看冲突标记更清晰； - 如果冲突块里只有缩进、空行、单双引号切换（比如
'abc'vs"abc"），大概率是编辑器自动格式化惹的祸——建议团队统一.editorconfig和 Prettier 配置，而不是每次手动选； - 真正要警惕的是函数签名变更、字段重命名、条件分支逻辑相反（比如
if (x > 0)vsif (x >= 0)）——这类必须人工核对业务含义。
快速解决：用 --strategy-option 减少干扰
如果你明确信任 main 分支的修改（比如只是同步基础框架升级），不想一行行挑，可以用策略选项跳过部分冲突判定：
-
git merge -X theirs main：当发生冲突时，自动采用main分支的版本（注意：仅对能自动合并的部分生效，不能绕过语法错误）； -
git merge -s recursive -X ignore-space-change main：忽略空格和换行差异，适合合并前刚跑过 Prettier 的场景； - 慎用
--no-commit：它不会跳过冲突，但能让你在git commit前再检查一遍暂存区，避免把半成品提交上去。
最常被忽略的一点：冲突解决后，git add <file></file> 是必须动作，不是可选步骤。Git 不会因为你删了冲突标记就自动认为“已解决”，它只认暂存区状态。漏掉这一步，git commit 会报错“no changes added to commit”，而你可能以为是命令输错了，其实只是忘了 add。
