刚 pull 完就 push 失败是因远程已有他人提交，Git 拒绝非快进推送；应先 git fetch 查看差异，再按需 merge 或 rebase，配合短生命周期分支、每日同步及关键文件协作约定，可显著降低真实冲突。
冲突无法完全避免，但高频、大面积的合并冲突基本都是流程或习惯问题，不是Git本身的问题。
为什么刚 pull 完就 push 失败？
这是最典型的“假冲突”：你本地没更新，远程已有别人提交，git push 被拒绝。Git 并没真正遇到代码级冲突，只是拒绝非快进（non-fast-forward）推送。
- 别直接
git pull—— 它自动fetch + merge，掩盖了中间状态，容易在不知情下引入意外变更 - 改用
git fetch先看远程动向：git status会明确告诉你 “Your branch is behind 'origin/main' by 3 commits” - 确认无误后再
git merge origin/main或git rebase origin/main，整个过程可控 - 如果本地有未推送提交，
rebase更干净；如果只是同步他人改动，merge更直白
feature 分支越长，冲突概率越高
一个持续开发 10 天的 feature/payment-refactor 分支，和每天合入 main 的 5 个短分支相比，前者冲突风险高出 3–5 倍（Atlassian 2025 团队数据）。
- 把大功能拆成原子任务，每个
feat/xxx生命周期控制在 1–3 天内 - 每天早间固定执行一次
git rebase origin/main（或git merge origin/main），让变更尽早对齐 - 避免在 feature 分支上长期积累大量与主线无关的调试代码或临时注释
- CI 流水线里加一道检查：如果某分支距
main超过 5 个提交，自动提醒负责人同步
哪些文件最容易引发真实冲突？
冲突高发区非常集中：package.json、requirements.txt、go.mod、路由配置、数据库迁移脚本、组件注册表 —— 它们常被多人同时修改且 Git 无法语义理解。
- 对这类文件，约定“谁新增依赖谁负责合并”，禁止多人并发编辑同一段
- 用工具约束：比如
pre-commithook 检查package.json是否按字母序排列，减少行序差异 - 数据库迁移不要用“自动递增编号”，改用时间戳前缀（如
202609041422_add_user_status.sql），避免命名冲突 - 共享配置类文件，考虑拆为
config/base.yaml+config/env/staging.yaml，降低交集面
真正的难点不在解决冲突，而在于让冲突发生时只影响最小范围的几行代码——这取决于日常推拉节奏、分支粒度和协作契约，而不是某个神奇命令。
