Git分支合并冲突是需人工决策的正常现象，非代码故障；冲突标记中<<<<<<< HEAD为当前分支修改、=======为分界、>>>>>>> feature/login为待合并分支修改；解决需手动编辑保留正确逻辑、删除标记后git add文件再commit；IDE自动解决有风险，应结合上下文谨慎处理。
Git不同分支合并时出现冲突，不是代码坏了，而是Git在等你做决定——它发现两个分支都改了同一处内容，不敢自作主张覆盖任何一方。
看到 <<<<<< HEAD 就手抖？先看懂标记结构
冲突文件里那段三段式标记不是乱码，是 Git 给你的决策界面：
-
<<<<<< HEAD下面是你当前所在分支（比如develop）的修改 -
=======是分界线 -
>>>>>> feature/login下面是待合并分支（比如feature/login）的修改
你不需要删整块，只需要保留逻辑正确的那一段，或者手动融合——比如把两行文案都保留、加个条件判断、或调用新旧函数共存。删完标记后，git add <file> 才算真正“解决”了这个文件。
用 git merge 合并失败后，别急着 git commit
执行 git merge feature/x 报错 “Automatic merge failed” 之后，仓库处于 MERGING 状态，此时：
- 不能直接
git commit—— 那会提交一个空的 merge 提交，冲突还在 - 必须先编辑冲突文件，删掉所有
<<<<<</=======/>>>>>>标记，并确保代码能运行 - 然后对每个已解决的文件单独执行
git add <file>（不是git add .，否则可能误加未解决文件） - 最后再
git commit，这次才是真正的合并提交
漏掉 git add 这步，commit 会失败或生成不完整合并，CI 流水线大概率卡住。
IDE 自动解决按钮有风险：慎选 “Use theirs” 或 “Use ours”
VS Code、IntelliJ、SourceTree 都提供一键采用某方版本的选项，但它们只看文本，不看语义：
- 选
Use theirs（即待合并分支的内容），可能删掉你刚在develop上修复的关键 bug - 选
Use ours（即当前分支内容），可能丢掉对方新加的功能入口或配置项 - 尤其当冲突出现在函数签名、API 返回结构、数据库迁移脚本里时，机械覆盖大概率导致运行时报错或数据不一致
建议：优先手动打开文件，对照 Git 贴出的两段差异，结合最近一次共同提交（git merge-base HEAD feature/x）确认上下文；复杂逻辑可临时写个测试验证行为是否符合预期。
冲突频繁？检查分支基线是否太久没同步
很多团队的冲突不是因为改得巧，而是因为拉得太晚：
- 如果
feature/x是从两周前的develop切出来的，而期间develop已合入 20+ 次提交，那冲突概率指数级上升 - 更稳妥的做法是定期用
git rebase develop（在feature/x分支上执行），把你的提交“挪”到最新develop顶端，提前暴露并解决小冲突 - 注意：rebase 后的提交 SHA 会变，已推送到远程的
feature/x需要强制推送（git push --force-with-lease），仅限自己独占的分支
真正难处理的从来不是单个冲突，而是几十个文件里分散着同一套重构逻辑的残留痕迹——那种时候，光靠删标记没用，得回溯设计意图，甚至找同事对齐改动边界。
