应使用git diff a...b（三点）而非git diff a..b（双点），因三点先自动计算两分支最近共同祖先，再对比该基线与b的差异，真实反映分支独有变更；双点仅机械对比两端快照，易产生误导性结果。
直接用 git diff 查远程分支差异，90% 的人默认写错参数——不是 git diff origin/main..origin/feature，而是 git diff origin/main...origin/feature（三个点）。双点比较的是两个引用的“快照差”，三点才真正找出“从共同祖先开始的独有变更”。这是代码审核前最容易漏掉的关键逻辑。
为什么 git diff A..B 和 git diff A...B 结果完全不同
双点语法（..）只对比两个提交对象的树状结构快照，不关心历史关系。比如 git diff origin/main..origin/feature 会把 origin/main 当作“左边”，origin/feature 当作“右边”，强行计算差异，哪怕 feature 分支早已合并过 main 的某些提交，也会重复显示那些改动。
三点语法（...）先自动算出两个引用的最近共同祖先（merge base），再执行 git diff <merge-base><b></b></merge-base>。这才是“这个分支到底新增了什么”的真实答案。
- 你刚
git pull origin main更新了本地 main，但远程origin/main可能已有新提交 → 此时origin/main和origin/feature的 merge base 不等于本地main提交 - 如果 feature 分支曾 rebase 过，双点 diff 会显示大量“删除旧 commit、新增相同内容”的假差异
- CI 脚本里硬写
git diff main..feature很可能漏掉已合并但未同步的远程变更
在 VSCode 里安全比对远程分支，别只信侧边栏
VSCode 源代码管理面板右键 “Compare with Branch…” 默认只拉取本地分支名，不会自动补全 origin/xxx。如果你没手动 fetch 过，它实际对比的是本地缓存的 origin/xxx 引用，可能落后于远程仓库数小时甚至数天。
- 操作前务必先运行
git fetch --all，确保所有远程跟踪分支更新到最新 - 在命令面板（
Ctrl+Shift+P）中输入 “Git: Compare Branches”，它支持输入完整远程引用名，如origin/main和origin/feature/login - VSCode 内置 diff 编辑器不显示 merge base 提交 ID，无法验证三点 diff 是否生效；需要终端补查：
git merge-base origin/main origin/feature/login
审核 PR 前必须确认的三件事
很多团队把 PR 页面当唯一依据，但 GitHub/GitLab 的 diff 视图默认使用三点逻辑（即 A...B），而本地环境若没 fetch 就直接 diff，结果就和平台不一致——这就是为什么“我在本地没看到冲突，合并时却报冲突”的根本原因。
- 检查当前本地仓库是否 clean：
git status显示无 untracked/unstaged 文件，避免干扰 - 确认远程引用已同步：
git ls-remote --heads origin | grep -E "(main|master)"对比 HEAD 提交哈希是否与git rev-parse origin/main一致 - 用
git log --oneline --graph origin/main...origin/feature/x看实际涉及哪些提交，而不是只看文件列表 —— 有些“空合并”提交会掩盖真正的变更范围
三点 diff 是 Git 审核链上最脆弱的一环：它依赖精确的引用状态、正确的参数、以及对 merge base 的信任。任何一环断开，你看到的“差异”就只是幻觉。别跳过 git fetch，也别省略 git merge-base 的验证步骤。
