冲突标记由三部分组成：> branch-name表示要合并分支代码结束；需对比两段内容，手动决定保留或合并后删除全部标记。
冲突标记怎么看：
看到 、<code>=======、>>>>>> feature/login 这三行，别删它们就跑——这是 Git 在告诉你“这里我没法自动选，你来定”。HEAD 指的是你当前所在分支的修改（比如你本地刚改的那几行），feature/login 是你要合并进来的那个分支的改动。
关键点在于：Git 只比对文本行，不理解代码逻辑。所以哪怕你删了一个函数，同事在同一个函数里加了注释，Git 也可能标成冲突——它只看到“同一块区域被两边动过”，而不是“这其实是兼容操作”。
- 相邻两行被不同人修改，Git 会大概率判为重叠变更（2023 年 GitLab 审计报告指出占比达 63%）
- 如果冲突块里有空行或缩进差异，也容易被误判；这类“假性冲突”建议先统一编辑器的保存格式（如 LF 换行、4 空格缩进）
- 不要直接删掉所有标记后随便留一版——得确认语义是否一致，比如一方删
password字段，另一方加passwordHint，自动合并成功不代表没风险
手动解决时该保留哪部分：别只看“谁最后改”
很多人下意识保留自己的修改，或者删掉对方的——这很危险。真正要判断的是：这段逻辑在当前上下文里是否还成立？有没有被其他模块依赖？
比如你在 utils/date.ts 里改了 formatDate 的默认时区，同事在同个函数里新增了国际化 fallback 逻辑。这时不能简单二选一，而要融合：把你的时区参数加进他的新签名里，再补上类型定义。
- 优先查最近一次共同祖先提交：
git merge-base HEAD origin/main，然后用git show <commit>:path/to/file</commit>看基线内容，确认两边改的到底是同一处语义 - 涉及 API 或类型定义（如
types.ts）的冲突，必须同步检查调用方代码，否则会出现运行时类型错误 - 配置文件（如
config.yaml）冲突，注意 key 的层级和数组顺序——YAML 对缩进和换行敏感，手工合并后建议用yamllint校验
用 git mergetool 能省事，但得配对工具
git mergetool 不是开箱即用的魔法，它只是个调度器，背后依赖你指定的图形化工具。没配好就运行，很可能卡在命令行里干瞪眼。
当用户提及 GitHub URL，或要求分析、审查、探索或理解任意 GitHub 项目、仓库或代码库时，请使用此技能。触发条件包括以下短语：“分析这个项目”、“看看这个仓库”、“analyze this repo”、“what does this project do”，或消息中包含任何 github.com URL。
推荐配一个带四面板的工具（比如 p4merge 或 VS Code 内置的合并编辑器），因为它能同时显示 base / local / remote / merged 四个版本，比三路对比更清楚改动来源。
- 全局启用 VS Code 合并工具：
git config --global merge.tool vscode，再加git config --global mergetool.vscode.cmd 'code --wait $MERGED' - 用
p4merge需提前下载安装，然后配git config --global merge.tool p4merge，否则git mergetool会报Unknown merge tool - KDiff3 等老工具在处理长文件（如 XML）时容易卡顿，可临时切到耐心算法：
git -c merge.algorithm=patience merge origin/main
解决完别急着 commit：先验证再推送
删完冲突标记、git add、git commit 之后，很多人以为万事大吉——但这时候最该做的，是立刻验证。
尤其要注意那些 Git 完全不感知的语义断裂：比如你保留了同事新加的字段，但忘了更新数据库迁移脚本；或者你融合了两个条件判断，却让某个分支路径永远走不到了。
- 运行受影响范围的单元测试，至少覆盖冲突文件的函数级用例
- 如果是前端项目，打开对应页面手动点一遍关键流程；后端则 curl 几个核心接口看返回
- CI 流水线因未解决冲突中断平均耗时 22 分钟/次，其中 47% 是因为本地没跑通就推了——别让团队等你
冲突本身不可怕，可怕的是把它当成“编辑任务”做完就交差。真正的难点永远在语义一致性上，而不是那几行标记怎么删。
