git pull触发合并冲突是因为其本质是git fetch加git merge，当远程与本地分支同时修改同一文件同一行时，git无法自动判断保留哪方修改，必须由用户手动解决。
Git pull 产生合并冲突时，不是代码坏了，而是 Git 在等你做决定——必须手动编辑文件、删掉冲突标记、再 git add 和 git commit 才算真正解决。
为什么 git pull 会触发合并冲突
因为 git pull 本质是 git fetch + git merge。当远程分支和你本地当前分支都修改了同一文件的同一行，Git 就无法自动判断该留谁的版本，于是停在合并中途，把选择权交给你。
- 常见诱因：你改了
config.yaml的数据库地址，同事也改了同一行但指向测试库；或两人同时在函数开头加了不同注释 - 注意：
git pull --rebase不会生成 merge 提交，但一样会遇到冲突，只是报错位置和恢复方式略有不同 - 冲突只发生在工作区（未提交的修改）与即将合并进来的远程变更之间；如果你本地有未
git add的脏文件，Git 通常会直接拒绝 pull，提示 “Please, commit your changes or stash them”
手动编辑冲突文件时怎么看懂那三段标记
打开冲突文件，你会看到类似这样的结构：
>>>>> origin/main
这三段不是乱码，而是 Git 给你的“决策面板”：
到 <code>=======之间：你本地分支（当前 HEAD）的修改-
=======到>>>>>> origin/main之间：从远程拉下来的、要合并进来的修改 - 你只需保留其中一段，或手动融合成新内容，然后**彻底删掉这三行标记**（包括
、<code>=======、>>>>>>） - 别只删中间一行——漏掉任一标记，
git add后仍会被识别为未解决冲突
解决后必须执行的两个命令缺一不可
编辑保存完文件，冲突还没结束。Git 需要你显式确认“这部分我搞定了”：
- 对每个已处理的冲突文件，运行
git add <file></file>—— 这步是告诉 Git：“这个文件的冲突我理清了，现在以当前内容为准” - 所有冲突文件都
git add完后，再运行git commit—— Git 会自动生成一条合并提交，你可直接保存默认信息，也可编辑说明 - 如果跳过
git add就直接git commit，Git 会报错 “no changes added to commit”，因为它根本不知道哪些文件算已解决
用 git mergetool 可视化解决更安全
纯文本编辑容易漏删标记或误删逻辑，尤其当冲突嵌套在长函数里。启用图形化工具能降低出错概率：
- 先配置一个工具，比如 VS Code：
git config --global merge.tool vscode，再设调用命令：git config --global mergetool.vscode.cmd 'code --wait $MERGED' - 运行
git mergetool，它会逐个打开冲突文件，在左右面板分别显示本地和远程变更，中间是可编辑的合并结果区 - 工具不会自动帮你选，但能高亮差异、防止误删、避免标记残留——对不熟悉冲突格式的新手尤其友好
- 注意：某些工具（如
kdiff3）需要单独安装，且首次运行可能提示配置路径
最容易被忽略的是：解决完一个文件后没立刻 git add，转头去改另一个文件，结果中间切分支或执行其他命令，导致状态混乱。记住节奏——改完即 add，全部 add 完才 commit。
