冲突不是错误，是git主动暂停等待人工决策；需用git status定位unmerged paths文件，git diff分析差异，手动编辑删标记并融合逻辑，再git add标记解决，最后git commit完成合并。
冲突不是错误，是 Git 在告诉你：这两处修改，它不敢替你做主。 本地和远程代码冲突发生时，Git 不会强行覆盖或丢弃任何一方——它停在原地，等你明确告诉它“留哪边、删哪些、怎么合”。关键不是“怎么跳过去”，而是“怎么看清再动手”。
git pull 触发冲突时，git status 显示 Unmerged paths
这是最常见也最容易被忽略的信号。运行 git status 后，如果看到类似这样的输出：
Unmerged paths:
(use "git add <file>" to mark resolution)
both modified: src/api/client.js
deleted by them: README.md</file>
说明 Git 已经识别出冲突，但还没进入编辑环节。此时不要急着打开文件，先确认三件事：
-
src/api/client.js是内容冲突（双方都改了同一段），而README.md是删除冲突（你没动它，远程把它删了）——处理方式完全不同 - 检查当前分支是否干净：
git status应无modified或untracked条目，否则先git add或git stash - 用
git log --oneline -n 5快速看最近几次提交，确认 HEAD 指向的是你预期的本地分支起点
打开冲突文件后， 和 <code>>>>>>> origin/main 之间不是“选项”，是上下文
这些标记不是让你二选一的菜单，而是 Git 提供的「变更快照」。比如：
function fetchUser() {
>>>>> origin/main
}
你需要判断的不是“留 timeout 还是 cache”，而是：
- 这两个改动是否互斥？
timeout和cache可以共存 → 手动合并成{ timeout: 5000, cache: true } - 是否其中一方已过时？比如
cache: true是新规范，timeout已被统一移除 → 直接删掉 HEAD 块，保留 origin 块 - 是否某方改动破坏逻辑？比如
cache: true导致用户数据不刷新 → 应该删 origin 块，甚至加注释说明原因
删完标记后，务必验证函数能否正常调用，而不是只看语法通过。
用 git add 标记解决，不是用 git commit 强行结束
很多人卡在这一步：改完文件、保存、直接 git commit，结果报错 “no changes added to commit”。因为 Git 要求你显式确认“这个文件我理清了”。正确流程是：
- 对每个冲突文件，执行
git add src/api/client.js—— 这步把文件从Unmerged状态移到staged - 再运行
git status，确认所有冲突文件都变成绿色的to be committed - 此时
git commit才能成功，且 Git 会自动生成合并提交信息，如Merge branch 'origin/main' into feature/auth
注意：git add 后如果发现改错了，可以立刻 git restore --staged src/api/client.js 撤回暂存，不用重开文件。
rebase 场景下，git rebase --continue 前必须 git add
如果你用 git pull --rebase 或手动 git rebase origin/main 遇到冲突，流程看似一样，但行为不同：
- 冲突发生在“重放你的提交”过程中，不是一次合并，而是逐个应用
- 每解决一个冲突文件，必须
git add，然后才能git rebase --continue - 如果中途想放弃整个变基，用
git rebase --abort，而不是git merge --abort - rebase 后的提交 SHA 会全部改变，所以如果已推过部分提交，后续要
git push --force-with-lease，不能直接git push
真正容易被忽略的是：rebase 冲突解决后，git status 不会显示 “all conflicts resolved”，它只显示你当前停在哪次提交上。靠 git rebase --continue 的反馈来判断是否真走完了，而不是靠眼睛扫状态。
