git分支冲突无法避免，关键在于通过频繁同步、语义化命名、.gitignore与pre-commit约束、codeowners路径所有权等措施让冲突变少、变小、可预期、可拆解。
大型敏捷团队里，Git分支冲突不是“会不会发生”的问题，而是“什么时候、在哪里、由谁来处理”的问题。预防的核心不是消灭冲突，而是让冲突变少、变小、变得可预期、可拆解。
为什么“频繁同步”比“等合并时再拉”更关键
很多团队把 git pull origin main 留到 merge 前一刻，结果发现本地分支和 main 已经 diverged 20+ commits——这时冲突往往跨文件、跨逻辑模块，解决成本指数级上升。
- 每天至少一次
git pull origin main（建议在晨会后或每日构建前执行） - 如果 feature 分支生命周期 > 3 天，强制要求每 48 小时做一次
git rebase main或git merge main（选其一并团队对齐） - CI 流水线中加入“分支新鲜度检查”：若 feature 分支落后 main 超过 5 个 commit，自动阻断 PR 提交，提示“请先同步 main”
feature 分支命名与生命周期必须带约束
没有约束的分支名（如 dev、new、fix）会导致多人误操作同一分支，或长期滞留无人清理。
- 强制使用语义化命名：
feat/user-login-v2、fix/api-timeout-408、chore/deps-upgrade-lodash - 所有 feature 分支必须关联 Jira/Clickup 等任务 ID，例如
feat/PROJ-1234-login-refactor - PR 合并后 24 小时内，自动触发脚本删除远端分支（GitHub Actions / GitLab CI 可配置）
- 禁止直接 push 到
main或release/*分支，全部走 PR + 至少 1 人 approve
.gitignore 和 pre-commit hook 是沉默的冲突过滤器
很多“伪冲突”其实来自 IDE 配置、日志、临时文件或本地环境变量——它们不该进版本库，但一旦进了，就会在不同人之间反复 diff、反复冲突。
- 团队级
.gitignore必须包含：/node_modules/、.env.local、*.log、.DS_Store、__pycache__/ - pre-commit hook 中加入文件扫描：拒绝提交含
console.log、debugger、TODO: fix me的 JS/TS 文件（用husky+lint-staged实现） - 对 config 目录启用 git attributes：在
.gitattributes中声明config/*.yml merge=ours，避免多人改同一配置文件时覆盖彼此
模块级代码所有权要落到文件路径上
“这个模块大家都能改”等于“这个模块谁都可能冲突”。大型项目必须明确谁对哪些路径有修改权。
- 在 CODEOWNERS 文件中定义路径归属，例如：
src/services/auth/** @backend-team、src/components/button/** @ui-team - PR 自动检查：若提交修改了非 owned 路径，CI 报 warning 并要求额外 reviewer 签名
- 每周同步会议中 Review CODEOWNERS 是否过期——人员变动、模块重构后，所有权必须同步更新
真正难的不是写 merge 脚本，而是让所有人习惯在改代码前先看一眼自己动的路径归谁管、自己的分支有没有落后 main、这次提交会不会把 .env 写进去。这些动作不靠工具强制，靠日复一日的节奏沉淀。
