必须先执行git fetch，因为origin/main等远程分支名只是本地过期的追踪引用；直接diff可能对比错误快照，应fetch后用git diff origin/main...origin/feature/login（三点）确保基于共同祖先计算差异。
直接对比远程分支和主干（如 origin/main 和 origin/feature/login）前，必须先 git fetch；否则看到的“差异”很可能是过期甚至错误的。
为什么 git diff origin/main origin/feature/login 有时没反应或结果反常
Git 的远程分支名（如 origin/main）只是本地存储的“追踪引用”，不自动随远端更新。如果上次 fetch 是三天前，那 origin/main 指向的 commit hash 可能早已落后。此时运行 git diff，实际比的是两个旧快照，不是当前远端真实状态。
- 执行
git ls-remote origin main查看远端当前 commit hash - 再执行
git show-ref origin/main对比本地追踪引用是否一致 - 若不一致，说明
fetch没生效——常见原因是拼错分支名（比如写成originn/main）、远端分支已被删除、或用了错误的 remote 名（如该用upstream却写了origin）
git log --cherry-pick --left-right origin/main...origin/feature/login 才是判断“是否合并完成”的可靠方式
单纯看文件差异容易误判：rebase 过的分支、cherry-pick 过的提交，内容相同但 hash 不同，git diff 会当成全新改动。而 --cherry-pick 能识别语义等价，真正回答“哪些提交只存在于某一分支”。
开头的行：只在 <code>origin/main上（main 有、feature 没有）-
>开头的行：只在origin/feature/login上（feature 有、main 没有） - 三个点
...表示对称差（symmetric difference），Git 自动找 merge base；两个点..是单向，容易方向搞反 - 输出为空 ≠ 没差异：先运行
git merge-base origin/main origin/feature/login确认是否存在共同祖先
用 git diff 看文件级变更时，别忽略参数细节
方向错了，patch 就是反的；漏了参数，关键信息就看不见。
-
git diff origin/main origin/feature/login：以origin/main为基准，“变成 feature 需要加什么”——但如果main实际比feature更新，结果会显示大量“删除”，误导性极强 -
git diff origin/main...origin/feature/login（三个点）：Git 自动算出 merge base，再 diff “base → feature”，这才是安全的“feature 新增了什么” - 加
--name-status才能看到重命名（R）、复制（C）、删除（D）等操作，纯git diff默认只显示内容变更的文件 - 加
--stat先快速扫一眼改了几个文件、增删多少行，再决定是否深挖细节
最易被忽略的一点：远程分支对比永远依赖本地追踪引用的 freshness。哪怕你刚 git pull 过，它只更新当前分支的 origin/xxx，其他分支的追踪引用仍可能 stale。真要严谨对比，每次都要 git fetch origin main feature/login 显式拉取目标分支，而不是依赖全局 git fetch 或 git pull。
