必须先 git fetch 再 git diff master origin/master，因为 origin/master 是远程追踪引用，只记录上次 fetch 时的提交哈希，未 fetch 则指向过期提交，导致差异不准或报错。
直接比 git diff master origin/master 之前，必须先 git fetch，否则看到的可能是过期差异甚至报错。
为什么 git diff 直接比远程分支名会失效
Git 的 origin/master 是“远程追踪引用”，不是本地 commit 对象。它只是一条指针，指向你上次 fetch 时远端的 master 提交 hash。如果远端已更新，但你没 fetch，这个指针就不会动——git diff 拿到的还是旧 commit，结果完全不准。
常见错误现象：
-
git diff master origin/master显示无差异，但git pull确实拉下了新提交 -
git show-ref origin/master输出的 hash 和git ls-remote origin master不一致 - 执行
git diff报错：fatal: ambiguous argument 'origin/master': unknown revision or path not in the working tree（说明该引用根本没被拉取）
正确对比本地分支与它所跟踪的远程分支
最省事、最不容易出错的方式是用 @{upstream} 语法，它自动解析当前分支配置的上游（比如 branch.main.remote 和 branch.main.merge）：
-
git diff @{upstream}—— 当前分支 vs 它的上游（如origin/main） -
git diff main@{upstream}—— 显式指定分支名，适合不在main分支时使用 -
git diff @{u}——@{upstream}的简写，效果相同
这个方式不依赖你是否记得 fetch，因为 Git 会在运行时自动检查引用有效性；如果上游引用缺失，会明确提示你先 git fetch。
想看文件级差异还是提交级差异？选对命令
git diff 只展示内容变更，git log 才能看清“谁提交了什么、有没有漏合”：
- 看哪些文件改了：
git diff --name-status @{u}（A新增、M修改、D删除） - 看哪些提交只在远程有（即本地还没拉）：
git log @{u}..HEAD（本地多出的提交） - 看哪些提交只在上游有（即本地落后）：
git log HEAD..@{u}（远程多出的提交） - 想确认 feature 是否已全量合并进 main：
git log --cherry-pick --left-right main...origin/feature/login，输出带/ <code>>标记
注意：三个点 ... 是对称差集，两个点 .. 是单向范围，别混用。
临时拉一个远程分支做可视化对比
某些场景下（比如要和 IDE 并排查看、或 diff 大量文件），把远程分支落地为本地临时分支更直观：
-
git fetch origin main:tmp-main—— 把远端main拉成本地tmp-main分支（不切换） -
git diff tmp-main—— 在当前分支下直接比 - 比完删掉：
git branch -D tmp-main
这个方法绕开了所有引用时效性问题，也避免污染 origin/* 追踪分支，适合需要反复验证或多人协作核对的场合。唯一要注意的是：不要用 git checkout -b tmp-main origin/main，那样会创建带上游设置的分支，后续 git pull 可能误操作。
真正容易被忽略的点是：很多人以为 git pull 后就万事大吉，但 pull = fetch + merge，而 merge 可能触发 fast-forward 或 conflict 解决逻辑——此时 origin/main 引用虽已更新，但你的工作区/暂存区状态可能已变。所以只要涉及“准确对比”，一律以 git fetch 后的干净状态为准，别依赖 pull 副作用。
