直接合并 origin/xxx 不安全，因远程跟踪分支需先 git fetch 更新；跳过 fetch 会基于过期提交合并，导致遗漏他人新推送的改动。
直接合并 origin/xxx 到本地分支是安全的，但前提是先 git fetch origin，否则可能拿的是过期的远程状态。
为什么不能跳过 git fetch 直接 git merge origin/xxx？
因为 origin/xxx 是一个**远程跟踪分支**，它不是实时更新的——Git 只在你显式运行 git fetch 或 git pull 时才去服务器拉取最新提交并更新这个指针。如果你很久没 fetch，origin/xxx 指向的可能是几天前的提交，合并后会漏掉别人已推上来的改动。
常见错误现象：
– 合并完发现同事昨天提的修复没进去
– git log origin/xxx 显示的最新 commit 时间明显早于远程仓库网页上看到的
– git status 提示 “your branch is behind 'origin/xxx' by N commits”（说明本地远程跟踪分支已落后）
正确做法：
- 始终先执行
git fetch origin（或git fetch origin xxx只拉指定分支） - 用
git log --oneline origin/xxx快速确认它是否真更新了 - 再执行
git merge origin/xxx
git merge origin/xxx 和 git pull origin xxx 有什么实质区别？
本质区别在于：后者 = git fetch origin xxx + git merge FETCH_HEAD，而前者只做合并动作，不保证 fetch。
使用场景差异：
- 想合并但不确定远程是否最新 → 用
git fetch origin xxx && git merge origin/xxx（两步，可控） - 确定远程分支稳定、且你信任当前
origin/xxx状态 → 可直接git merge origin/xxx - 想省事且接受自动 fetch+merge → 用
git pull origin xxx，但注意它默认触发merge，不是rebase
性能影响：无实质差异；兼容性上，git pull 在某些老旧 Git 版本中对非默认分支支持略弱，而 git fetch+git merge 更通用。
合并时遇到 “CONFLICT (rename/add)” 怎么办？
这类冲突不是代码行冲突，而是 Git 对文件路径变更的理解分歧。典型报错：CONFLICT (file location): .../default_poses.csv added in origin/dev inside a directory that was renamed in HEAD...
原因：一方重命名了目录（比如 poses/ → poses_data/），另一方在原目录下新增了同名文件。Git 不知道该把新文件放哪。
解决关键点：
- 别直接删或改冲突标记 —— 这类冲突没有
<<<<<< HEAD块，靠 Git 自动判断失败触发 - 手动检查两个变更：
git show origin/dev:old/path/default_poses.csvvsgit ls-tree -r HEAD | grep default_poses.csv - 决定最终路径：如果重命名合理，就用
git mv把新文件移到新位置；如果不合理，就git rm掉重命名操作（需先git reset HEAD old/path/） - 最后
git add新路径文件，再git commit
合并后要不要立刻 git push？
不一定。尤其当你合并的是他人正在活跃开发的远程分支（如 origin/dev）时，合并提交本身没问题，但立即 push 可能导致后续协作混乱。
容易踩的坑：
- 你 merge origin/dev → 生成一个合并提交 A → push → 此时
origin/dev已含 A - 同事 B 在你 push 前也 merge origin/dev → 生成合并提交 B → 他 push 成功 → 你再 push 就会失败（non-fast-forward）
- 结果是你得再 fetch + merge B → 又多一个合并提交 C，历史变臃肿
建议节奏：
- 合并后先本地验证（跑测试、看功能）
- 确认无误再
git push origin <your-branch> - 若目标是同步到主干（如 main），且团队约定“仅 maintainers 推送”，则合并后不 push，等 Code Review 通过再由负责人操作
真正容易被忽略的是：合并操作本身不危险，危险的是合并后的“推送时机”和“分支所有权认知”。很多团队冲突不是出在 merge 命令，而是出在谁该 push、什么时候 push、push 前有没有确认远程分支是否已被他人更新。
