结论：不规范同步流程必然导致团队协作事故——需严格区分git pull（fetch+merge/rebase）与fetch，feature分支必须基于最新dev创建，推送前须检查远程状态，定期prune过期远程引用，并养成操作前3秒思考习惯。
直接说结论：不规范同步流程，团队协作迟早出事——不是冲突解决不了，而是没人知道当前该基于哪个分支、谁的代码还没合、线上问题该从哪找源头。
git pull 和 git fetch 的区别必须分清
很多人以为 git pull 就是“把远程更新拿过来”，其实它等于 git fetch + git merge（或 git rebase，取决于配置）。这在多人高频提交时非常危险：
-
git pull origin dev会自动合并远程变更到当前分支，如果本地有未提交修改，可能触发意外合并； - 更稳妥的做法是先
git fetch origin查看远程分支状态（比如git log ..origin/dev看差多少提交），再决定用merge还是rebase； - 团队统一配置
git config --global pull.rebase true可让pull默认走变基，避免无意义的“merge commit”，但要注意：已推送的提交不要rebase。
feature 分支必须从最新 dev 拉取，不能“凭感觉”切
常见错误是：早上拉了 dev，下午才建 feature/login，结果别人中午已经 push 了两轮，你的分支起点就落后了。等你开发完提 PR，冲突量陡增。
正确做法是严格按顺序执行：
git checkout dev-
git pull origin dev（确保本地dev是最新） -
git checkout -b feature/user-login（此时新分支的 base 才真正干净）
别省这三步。CI 流水线里也可以加检查：PR 的 base 提交必须和 origin/dev 的 HEAD 一致，否则拒绝合并。
推送前不检查远程状态，90% 的 “rejected” 都因此而来
git push origin feature/user-login 报错 Updates were rejected because the remote contains work that you do not have locally？这不是 Git 在刁难你，是它在提醒：“你本地分支已经落后于远程同名分支”。
原因通常是：别人也推过同名分支（比如都用了 feature/login），或者你上次推送后，有人 force-push 覆盖过该分支（虽不推荐，但真会发生）。
应对方式只有两个：
- 先
git fetch origin，再git rebase origin/feature/user-login（仅限未共享的私有分支）； - 或
git merge origin/feature/user-login（适合已公开、多人协作的特性分支）； - 绝不要直接
git push --force，除非你确认整个团队都同步了这次重写。
本地残留远程分支引用容易误导判断
git branch -a 显示一堆 remotes/origin/feature/xxx，但实际远程仓库里那个分支早就被删了？这是 Git 的正常行为：fetch 不会自动清理已不存在的远程分支引用。
手动清理命令是 git remote prune origin，建议把它加入日常同步习惯：
git fetch origingit remote prune origin-
git branch -r（确认列表已刷新）
否则你会对着一个“幽灵分支”反复尝试 git checkout 或 git merge，浪费时间还搞混上下文。
最易被忽略的一点：同步流程不是写在文档里的漂亮步骤，而是每个开发者每次敲命令前的 3 秒停顿——想清楚“我当前在哪、我要同步谁、我有没有权限动这个分支”。Git 不会替你做判断，它只忠实地执行你输入的每一行指令。
