Git冲突本质是多人修改同一文件同一区域，Git无法自动判断取舍，需人工解决；标记<<<<<<< HEAD为当前分支代码，>>>>>>> branch为被合并分支代码，解决后必须git add再git commit。
提交代码本身不难，难的是合并时突然冒出一堆 <<<<<< HEAD —— 这说明你和别人改了同一段代码，Git 把选择权交给你了，不是它坏了，是你得拍板。
git add / git commit 之前先确认状态
很多人一上来就 git add .，结果把临时文件、日志、IDE 配置全塞进暂存区。这会导致后续提交混乱，甚至把敏感信息推到远程。
- 用
git status -s看哪些文件是M（已修改）、A（新增）、??（未跟踪），重点关注标红的那些 - 只加真正要提交的：比如只提交
src/utils/api.js，就运行git add src/utils/api.js，别图省事git add . - 如果改了但还不想提交（比如调试用的
console.log），用git restore <file>撤回工作区改动，或git add -p交互式选块暂存 - 提交信息别写“update”或“fix bug”，用
git commit -m "feat(auth): add token refresh logic"这种带作用域和动词的格式，方便后期查问题
git merge 触发冲突的典型场景
冲突不是随机出现的，基本就三种情况：改同一行、删 vs 改、改 vs 改但内容不同。最常见的是你在 feature/login 分支改了 login.js 第12行的 URL，同事在 main 上也动了同一行。
- 执行
git merge main（当前在feature/login）时，Git 会找两个分支的merge-base，再比对各自相对于基点的变更 - 只要变更区域重叠且内容不一致，就会停在冲突文件，不会自作主张选一个
- 注意：
git pull本质是git fetch + git merge，所以拉代码时也可能触发冲突，不只是显式merge - 图形化工具（如 VS Code 内置 Git 面板）会高亮冲突块，但底层标记完全一样：
<<<<<< HEAD是你本地分支的内容，>>>>>> main是被合并分支的内容
手动解决冲突的实操要点
别删标记就完事——删完可能语法错误、逻辑断裂、调用不匹配。得看懂两边改了什么，再决定怎么融合。
- 打开冲突文件，找到
<<<<<< HEAD到>>>>>> main之间的全部内容，逐行对比语义，不是只看字面 - 如果一方改了函数参数，另一方改了调用处，必须同步调整，否则运行时报
TypeError: xxx is not a function - 解决完后，**必须**运行
git add <conflicted-file>告诉 Git “这段我理清楚了”，否则git commit会拒绝 - 不要用
git commit -a跳过add，它不会自动把已解决的冲突文件加入暂存区 - 提交时用
git commit（不带-m），编辑器里默认消息已包含 “merged main into feature/login”，保留即可
为什么有时候 git merge 不报冲突，但代码却出错
这是比明面冲突更危险的情况：Git 认为能自动合并，但逻辑上已经矛盾。比如你删了一个函数，同事在另一个文件里新加了对它的调用——Git 只看文件行变化，不理解函数是否还存在。
- 这类问题不会出现冲突标记，但编译失败或运行时报
ReferenceError - 解决办法只有两条：合并前跑一遍本地测试（
npm test或python -m pytest），以及合并后立刻在 CI 流水线里验证 - 团队可以约定：涉及接口、函数签名、配置结构的改动，必须在 PR 描述里明确写出影响范围，提醒 Reviewer 重点检查调用链
- 别依赖 Git 的“自动”能力来保逻辑正确，它只保文本可合并
冲突标记只是 Git 给你的提示条，不是障碍；真正容易被忽略的是：改了实现，没同步改调用；删了字段，忘了删 JSON Schema；或者合并完没验证边界 case。这些都不会在 <<<<<< 里显示，但上线后立刻暴露。
