Git冲突本质是多人修改同一段内容时Git无法自动判断逻辑合理性，属协作必然信号而非错误；常见诱因包括分支混用、同步滞后、公共文件重叠修改等。
不能完全避免，但可以大幅降低发生频率和解决成本——关键不是“不冲突”，而是让冲突变得可预期、可定位、可快速收口。
为什么 git merge 总是报 conflict？
冲突本质是 Git 在告诉你：“你和别人改了同一段内容，我没法自动判断谁的逻辑更合理。”这不是命令写错了，也不是仓库坏了，而是协作中必然出现的信号。常见诱因包括：
- 多人长期在
main或dev上直接提交，没有隔离开发边界 - 拉取远程更新不及时，本地分支落后多个提交后才 push
- 修改了同一个配置文件（如
package.json、.env）或公共工具函数，且改动区域重叠 - 合并前没做
git fetch，只靠git pull自动 merge，把同步和集成混在一起
用 rebase 替代 merge 同步上游变更
当你需要把远程分支的新提交“吸进来”时，git pull 默认执行 git fetch + git merge，会生成无意义的 merge commit；而 git pull --rebase 执行的是 git fetch + git rebase，把你的本地提交“挪”到远程最新提交之后，历史保持线性，冲突也只在 rebase 过程中集中暴露一次。
- 推荐日常同步使用：
git pull --rebase origin main - 如果本地有未提交修改，rebase 前 Git 会拒绝执行，这时先
git stash，rebase 完再git stash pop - rebase 中遇到冲突，解决后用
git add <file>标记已处理，再git rebase --continue - 切忌在已推送到远程的提交上 rebase —— 这会重写历史，影响他人
功能分支命名与生命周期要严格
分支不是临时草稿纸，它代表一段明确的开发意图。命名不清、保留过久、随意推送，都会放大冲突风险。
- 分支名必须带语义，例如
feat/user-login、fix/header-xss，禁用dev1、tmp这类名称 - 一个分支只做一件事，完成即合入，不要在上面叠加新需求
- 合入后立即删除远程分支：
git push origin --delete feat/user-login - 本地分支也建议定期清理：
git branch --merged | grep -v "main\|master" | xargs git branch -d
哪些文件最容易引发隐蔽冲突？
有些文件看似普通，但多人同时修改极易触发“逻辑冲突”——Git 能检测出文本差异，却无法理解业务含义。
-
package.json：依赖版本升级、脚本新增，不同人加的 script 名可能重复 -
README.md：多人各自补充说明，章节顺序、格式风格不统一，diff 看似简单，合并后结构可能错乱 - 数据库迁移文件（如
migrations/20260920_add_user_status.js）：序号、表名、字段名稍有偏差，上线就报错 - 配置类 JSON/YAML（
config/prod.yaml）：key 相同但 value 类型不一致（字符串 vs 对象），运行时报解析失败
这类文件建议约定编辑权归属人，或引入预提交钩子（pre-commit）做格式校验，而不是等 push 时才发现冲突。
