Git合并冲突是Git要求人工决策的正常提示，需删除<<<<<<< HEAD、=======、>>>>>>> feature/login三段标记，仅保留最终代码；解决后必须依次执行git add <file>和git commit完成合并，不可跳过任一环节。
Git合并分支出现冲突，不是代码坏了，也不是你操作错了——它只是 Git 在告诉你：“这两份修改我都看到了，但我不知道该信谁，得你来拍板。”
看到 <<<<<< HEAD 就别慌，先看懂标记含义
冲突文件里出现的三段式标记不是 bug，是 Git 给你的决策界面：
-
<<<<<< HEAD后面是你当前所在分支（比如master）的代码 -
=======是分界线，不是注释，不能留着 -
>>>>>> feature/login后面是你要合并进来的那个分支（比如feature/login）的代码
注意：这些符号必须全部手动删掉，只保留最终要运行的那一版代码。哪怕只多留一个 <，编译或运行时都可能直接报错。
手动编辑解决后，git add 和 git commit 缺一不可
改完文件只是“人脑决策完成”，Git 还不知道你已解决——它只认状态，不读心：
- 用
git status确认冲突文件状态变成both modified（而不是unmerged） - 对每个解决完的文件执行
git add <file>，这是向 Git 发出“我确认过了”的信号 - 然后必须
git commit（不用加-m，Git 会自动提供默认提交信息），否则合并仍处于“暂停”状态 - 如果跳过
git add直接git commit，Git 会报错：no changes added to commit
别用 git merge --abort 逃避，除非真想放弃整个合并
很多人一见冲突就下意识想回退，但 git merge --abort 会丢弃所有尚未 add 的编辑内容，包括你已经花时间理清逻辑、手动合并好的部分：
- 它只适用于：你刚打开文件，还没动任何一行，就想彻底放弃这次合并
- 如果你已经改了 5 个文件中的 3 个，再 abort 就等于白干，还得重来
- 更稳妥的做法是：逐个
git checkout --ours <file>或git checkout --theirs <file>恢复某一个文件的某一方版本，再局部调整
真正容易被忽略的点：冲突不止发生在“改同一行”
新手常以为只有改了同一行才冲突，其实 Git 对“同一区域”的判定很宽松：
- 两处修改相隔 ≤3 行，Git 默认视为“同一块”，会主动标冲突（可调，但不建议初学者碰
merge.conflictStyle） - 一方删了函数，另一方修了这个函数里的 bug —— 表面没改同一行，但 Git 认为“删除”和“修改”互斥，必冲突
- 一方重命名文件 A → B，另一方还在改 A —— Git 把这当成“A 被删 + B 被建 + A 被改”，三重冲突叠加
这类场景没法靠删标记解决，得先理解业务意图：那个函数到底还有没有调用？重命名是不是已同步通知所有人？否则选了“ours”或“theirs”，上线就炸。
