冲突的本质是本地与远程仓库在同一代码位置发生了无法自动合并的修改，此时必须人工介入判断并决定保留哪一部分。首先使用 git status 检查尚未解决的冲突，接着在文件中定位由 <<<<<< HEAD 至 >>>>>> 标记的冲突区域，删除这些标记，并手动保留或融合代码，最后执行 git add 和 git commit 完成合并操作。
当你在团队协作中执行 git pull 或 git merge 时，如果看到“CONFLICT (content): Merge conflict in xxx.js”这样的提示，就意味着本地修改与远程版本在相同位置发生了无法自动合并的变更，需要人工介入判断取舍。用最直观的说法——冲突就像两个人同时移动了同一块石头，现在需要你来决定保留哪一块。
第一步：确认冲突真实存在且尚未解决
运行 git status 命令，查看输出中是否明确列出“Unmerged paths”或文件名后带有“both modified”标记。如果只显示“Your branch is up to date”，则说明没有冲突，无需强行处理。
打开终端，输入 git log --oneline --graph --all，快速查看当前分支与目标分支（如 origin/main）的分叉点，确认你确实处于 merge/pull 后的未完成状态。
第二步：定位冲突文件并理解冲突标记
从 git status 的输出中，记下所有标为“Unmerged paths”的文件路径，例如 src/utils/date.js。
使用任意文本编辑器打开该文件，你会看到类似下面的冲突区块：
<<<<<< HEAD
function formatDate() { return new Date().toISOString(); }
=======
function formatDate(format) { return moment().format(format); }
>>>>>> a1b2c3d其中 <<<<<< HEAD 到 ======= 之间的代码是你本地分支的修改，======= 到 >>>>>> 之间的代码是要合并进来的远程分支的修改（commit ID 后缀可忽略）。关键操作：必须删除这三行标记本身，但不能只删除标记而保留两段代码，否则冲突仍然存在。
第三步：决定保留哪段逻辑，或手动合成新逻辑
方法一：完全采用远程版本（放弃本地修改）——删除从 <<<<<< HEAD 到 ======= 的全部内容（包括标记），只保留 ======= 下方到 >>>>>> 之间的代码，再删除这两行标记。
方法二：完全采用本地版本（丢弃对方修改）——删除从 ======= 到 >>>>>> 的全部内容（包括标记），只保留 <<<<<< HEAD 上方到 ======= 之间的代码，再删除标记。
方法三：手工融合（推荐大多数情况）——例如本地返回 ISO 字符串，远程支持 format 参数，那么可以写一个兼容两者的新函数：function formatDate(format) { return format ? moment().format(format) : new Date().toISOString(); }，然后将整个冲突区块（包含 <<<<<<、=======、>>>>>>）全部删除，只保留这一行新代码。
第四步：标记冲突已解决并提交合并结果
保存文件后，在终端执行 git add src/utils/date.js（对每个冲突文件重复此操作）。
运行 git commit，编辑器会自动弹出默认的合并提交信息，直接保存并退出即可。Git 此时会生成一个合并提交对象，HEAD 指针向前移动，冲突正式解决。
最后验证：运行 git status，应显示“nothing to commit, working tree clean”；再运行一遍单元测试或手动检查功能，确保融合后的逻辑行为符合预期。