合并冲突是 Git 的正常机制，提示两分支对同一代码段做了不可自动合并的修改；理解冲突标记、正确取舍并执行 git add 与 git commit 即可解决。
合并冲突不是 Git 的 bug，而是它在告诉你：两个分支对同一段代码做了不可自动协调的修改。只要理解冲突标记的含义、知道该删什么留什么、再走完 git add + git commit 这两步，就能稳住节奏不熬夜。
看到 CONFLICT (content) 和
执行 git merge feature 后如果终端输出类似：
CONFLICT (content): Merge conflict in src/utils.js Automatic merge failed; fix conflicts and then commit the result.
说明 Git 已暂停合并，且已在冲突文件中插入三段式标记。此时不要直接 git commit，也不要盲目删掉整个文件重写。
-
git status会列出所有状态为 both modified 的文件，这是你必须处理的清单 - 打开对应文件，找到形如
<<<<<< HEAD→=======→>>>>>> feature的块，仅这块内容需人工干预 -
<<<<<< HEAD到=======是当前分支（比如main）的修改；=======到>>>>>> feature是待合并分支的修改 - 保留逻辑正确的一方，或手动合并两者（比如函数参数补全 + 新增返回值处理），**必须删掉全部三行标记**，否则提交后代码会语法报错
git mergetool 不是玩具，是节省时间的关键工具
靠肉眼比对十几处冲突容易漏改、手抖多删一行。用图形化工具能直观看到“左边是 HEAD、右边是 feature、中间是结果”，改完点保存即同步到工作区。
- 先配一个可用工具：
git config --global merge.tool vscode（VS Code）或git config --global merge.tool meld（需提前装 Meld） - 运行
git mergetool，它会逐个打开冲突文件；工具里选“Accept Current Change”“Accept Incoming Change”或手动编辑中间栏 - 每解决一个文件，工具会自动执行
git add <file>；全部完成后，只剩git commit一步 - 注意：某些工具（如 VS Code）默认不删除冲突标记，需确认“已解决”并保存，否则仍算未 resolve
rebase 场景下的冲突和 merge 本质一样，但上下文不同
执行 git rebase main 时遇到冲突，表面看命令不同，但冲突标记格式、解决方式完全一致。区别在于：rebase 是把你的提交一个个“重放”到新基线上，所以每次冲突解决后要运行 git add <file> + git rebase --continue，而不是 git commit。
- 别用
git commit终止 rebase 流程，那会导致一个多余的合并提交，破坏线性历史 - 如果卡在某次冲突不想继续，可用
git rebase --abort回退到 rebase 前状态 - rebase 中的冲突往往比 merge 更频繁——因为你是在重放多个提交，每个提交都可能撞上基线改动
真正容易被忽略的不是怎么解冲突，而是没意识到：只要工作区有未提交改动，git pull 或 git merge 都可能直接拒绝执行，报错 Your local changes would be overwritten。这时得先 git stash 把改动暂存，合并完再 git stash pop 拿回来——否则连冲突界面都进不去。
