冲突不是错误，是 Git 在等你做决定；处理核心就三步——看标记、选逻辑、提交确认。Git 用三路合并算法发现两边修改同一段代码后，插入<<<<<<< HEAD、=======、>>>>>>> origin/main标记，对应merge-base、HEAD和origin/main三个版本，需人工删标记、留逻辑、git add后git commit完成合并。
直接说结论：冲突不是错误，是 Git 在等你做决定；处理核心就三步——看标记、选逻辑、提交确认。
看到 <<<<<< HEAD 和 >>>>>> origin/main 别慌
这是 Git 用三路合并算法发现“两边都改了同一段代码”后留下的协商标记，不是文件损坏。它对应三个版本：merge-base（共同祖先）、HEAD（你本地最新）、origin/main（远程最新）。Git 已经把差异摊开给你看了，接下来你要做的只是删掉无用部分、保留合理逻辑、清理标记。
- 只保留本地修改？删掉
=======和>>>>>> ...及之后内容 - 只接受远程？删掉
<<<<<< HEAD到=======之间内容 - 需要融合？手动拼接两段逻辑，确保语义正确，再删掉全部标记
- 千万别只删标记不删内容，否则会引入重复或语法错误
git pull 失败后，git status 是第一反应动作
它能立刻告诉你哪些文件处于 Unmerged 状态，以及当前分支是否干净。如果输出里有 both modified:，那就是文本冲突文件；如果有 both added: 或 deleted by them:，说明是文件级操作冲突（比如两人同时新建同名文件，或一人删、一人改）。
- 冲突文件没出现在
git status输出里？检查是否漏了git add—— Git 要求你显式标记“已解决”才会继续 - 看到
untracked files同时存在？先确认这些文件是否该进版本库，避免误加敏感配置 - 如果
git status提示Your branch is ahead of 'origin/main' by X commits却又拉不下来，大概率是你本地有未提交改动，Git 拒绝覆盖（形态A冲突）
想跳过手动编辑？git checkout --ours 和 git checkout --theirs 要慎用
这两个命令能一键丢弃某一方的变更，适合明确知道“必须全用本地”或“必须全用远程”的场景，比如修复线上紧急 bug 后回退测试代码。但它不区分文件内局部修改，整文件覆盖，容易误伤。
-
git checkout --ours path/to/file.go：用当前分支版本覆盖冲突区 -
git checkout --theirs path/to/file.go：用远程分支版本覆盖冲突区 - 执行后仍需
git add path/to/file.go标记为已解决 - 对配置文件、.env、package-lock.json 这类机器生成文件慎用——它们的“冲突”常是哈希或时间戳差异，人工比对反而更安全
冲突解决后，git commit 不是可选项，是必走流程
Git 把解决冲突的过程视为一次合并操作，必须通过提交固化结果。不提交，分支就卡在“合并中”状态，后续 git push 会失败，git log 也会显示悬空的 merge-base。
- Git 会自动生成类似
Merge branch 'origin/main'的提交信息，可直接用 - 如果想写清楚决策依据（比如“保留登录态校验逻辑，移除过期 mock 接口”），建议手动编辑提交信息
- 提交后运行
git push。若提示non-fast-forward，说明别人又推了新提交——此时别硬推，应再git pull一次，很可能又出新冲突 - 真正容易被忽略的是：冲突解决后的提交，会成为后续所有 rebase / cherry-pick 的新基线，所以逻辑准确性比速度更重要
