你在公司写完一段代码，正准备提交，同事小张也改了同一块功能。你一推代码，Git 回你一句：CONFLICT。这时候别慌，这就是典型的提交记录冲突，每个开发者都踩过这坑。
冲突是怎么来的？
Git 不是万能同步器。当你和别人同时修改了同一个文件的同一行，Git 没法猜谁对谁错，只能停下来让你手动决定。比如你把变量名改成 userName，小张改成了 userNickname，系统不知道该留哪个，冲突就产生了。
看到冲突别删分支
新手常见操作：冲突了，干脆删掉本地分支重新拉？这招虽然快，但你的修改可能白干了。正确做法是打开那个标红的文件，你会看到类似这样的内容：
<<<<<<< HEAD
const userName = "张三";
=======
const userNickname = "老三";
>>>>>>> abc1234 (origin/main)
上面那段是你本地的改动，下面那段是远程的提交记录。你需要手动删掉不要的部分，保留最终要的代码，比如：
const userName = "张三";
然后删掉那几行分隔符，保存文件。
标记清理后该干嘛？
改完文件，不代表完事。得告诉 Git 你处理完了：
git add .
git commit -m "合并登录逻辑，解决用户名字段冲突"
这时候的提交会自动生成一个合并节点。如果你用了 git pull --rebase，流程稍不一样，但核心思路不变：先理清改了啥，再明确留啥。
怎么减少这种麻烦？
团队协作时，别闷头写一天代码再提交。越早 push，越早暴露潜在冲突，修起来也轻松。另外，拆小功能、多沟通改动范围，比如提前说“我今天要动用户模块”，能避免多人撞车。
还有一个实用技巧：用 VS Code 或 WebStorm 这类编辑器，它们能高亮冲突区块，点个按钮就能选“接受当前”或“接受传入”，省得手敲。
历史提交也能冲突？
有时候你 rebase 老提交，比如想修改三四天前的一次 commit 信息，也可能触发冲突。原因一样：你改的代码块，后来别人也在新提交里动过。处理方式也一样——打开文件，手动合并，保存，继续 rebase 流程。
git rebase --continue
只要没搞错逻辑，这类操作其实比想象中安全。
别怕冲突，它是协作的证明
项目越活跃，冲突越多。这不是 Git 的问题，反而是多人高效协作的正常现象。关键不是避免它，而是熟悉流程，快速应对。下次看到 Merge conflict，别头皮发麻，打开文件，一行行看过去，搞清楚差异，做出选择就行。