遇到pull冲突别慌，先搞清楚发生了什么
你正忙着改一个数据库配置脚本，同事也在同一文件里调整连接参数。当你执行 git pull 想同步最新代码时，终端突然跳出 conflict 提示——这是 Git 在告诉你：两边都改了同一块内容，它没法自动决定用谁的。
这种情况在团队协作中太常见了，尤其多人维护同一个 SQL 初始化脚本或 ORM 映射文件时。关键不是避免冲突，而是学会快速、安全地处理它。
看看冲突长什么样
执行 git pull 后如果出现冲突，Git 会在文件中标记出冲突区域，像这样：
<<<<<<< HEAD
your local changes here
=======
incoming changes from remote
>>>>>>> branch-name上面那段是你本地的修改，下面那段是远程拉下来的。Git 停下来等你手动决定保留哪边，或者两边都做调整。
三种处理方式，按需选择
最直接的办法是打开冲突文件，删掉不需要的部分，保留最终想要的内容。比如你发现同事改的数据库端口更准确，那就删掉自己那部分，连同 <<<<<<< 和 ======= 这些标记一起清理干净。
改完后执行：
git add filename.sql把文件加入暂存区，表示冲突已解决。接着提交：
git commit -m "resolve conflict in db config"Git 会生成一次合并提交，pull 流程继续完成。
想放弃本地修改？一键回退也行
有时候你意识到自己的改动没必要保留，可以直接丢掉，完全采用远程版本。比如：
git checkout --theirs path/to/file.sql
git add path/to/file.sql或者反过来，坚持用本地的：
git checkout --ours path/to/file.sql
git add .这招适合改乱了又懒得手动对比的时候。
用工具看差异，心里更有底
光靠肉眼比对容易出错，尤其是大段 SQL 或 JSON 配置。可以配个可视化合并工具，比如 VS Code 内置的合并编辑器，点几下就能选块合并。命令行下也可以用 git mergetool，前提是提前配置好工具路径。
平时多用 git diff 看看即将拉取的变更，提前预判有没有重叠修改。养成习惯后，冲突次数会明显减少。
预防胜于治疗，协作时注意这些细节
把大文件拆小，比如按模块分数据库脚本，减少多人同时碰同一文件的概率。提交时写清楚日志，让别人一看就知道你改了什么。定期同步远程分支，别让本地偏离太久，否则一口气拉几十个提交，冲突概率直线上升。
处理冲突不可怕，关键是别瞎操作。保存好现场再动手，不确定时先 git stash 存一下，解完了再 pop 出来核对。稳一点，代码才不容易出问题。