git diff 的参数顺序决定比较方向：git diff A B 表示“从A到B的变更”，即B相对于A的增改删；常用场景应为 git diff main develop 查看feature比主干多出的内容，三点语法 git diff main...develop 可排除合并噪声。
直接用 git diff 就行，但顺序和参数写错会导致“看反了”——比如你以为在看 feature 里加了啥，实际输出的是 main 里删了啥。
git diff develop main 和 git diff main develop 的区别
这是最常踩的坑：Git 总是计算「从第一个参数到第二个参数」的变更。也就是说：
-
git diff develop main：展示「把 develop 变成 main 需要删哪些、改哪些、加哪些」→ 实际是看 main 相对于 develop 的新增/修改（即 main 有而 develop 没有的内容） -
git diff main develop：展示「把 main 变成 develop 需要做的改动」→ 这才是你通常想看的：feature 分支比主干多出了什么
如果你在 feature/login 分支上执行 git diff main develop，结果可能为空或混乱，因为当前分支不参与命令逻辑——git diff 只认参数，不认当前检出状态。所以别依赖“我在哪个分支”，老老实实写全两个分支名。
只看改了哪些文件，不看具体内容
当分支差异巨大（比如几百个文件），先快速过一遍变更范围更高效：
-
git diff --name-only main develop：只列出文件路径，不含行级差异 -
git diff --name-status main develop：额外显示状态（A新增、M修改、D删除、R重命名），对重构类变更特别有用 -
git diff --stat main develop：带增删行数统计，一眼看出哪些文件动得最多
注意：--name-only 不会告诉你某文件是重命名还是删除+新建，这时候必须用 --name-status，否则可能漏掉关键线索。
在 VSCode 里可视化对比，但得避开自动分支识别陷阱
VSCode 的「Compare Branches」功能很直观，但它默认把「当前检出分支」当源分支。如果你在 develop 上右键选「Compare with main」，它实际执行的是 git diff develop main ——这又回到了上面的顺序问题。
- 正确做法：用命令面板
Ctrl+Shift+P→ 输入Git: Compare Branches→ 先输main（基准），再输develop（比较目标） - 或者，在资源管理器中右键
main分支 → 选Compare with Current Branch，前提是当前在develop上且你确认这个顺序符合预期 - VSCode 的 diff 视图里，绿色是
develop独有内容，红色是main独有内容——颜色本身不暗示“谁该被保留”，只是忠实反映参数顺序
如果看到大量红色块，别急着认为「这些要删」，先核对命令参数是否真按你想要的方向写的。
跳过合并提交干扰，专注真正差异
如果 main 和 develop 有频繁合并，git diff main develop 会包含大量「合并带来的重复变更」，比如某个 hotfix 已经合入 main，又被 merge 到 develop，diff 里却显示为「develop 多了一堆东西」。
- 用三点语法：
git diff main...develop（三个点）→ 它找的是两个分支「最近共同祖先」到develop的变更，自动过滤掉已同步进 main 的部分 - 等价命令：
git diff $(git merge-base main develop)..develop - 这个模式才是 Code Review 场景下真正该用的，否则你会被噪声淹没
复杂点在于：如果分支长期未同步，merge-base 可能非常靠前，导致 diff 结果过大；这时候得配合 --name-only 先筛文件，再挑重点文件用两点语法细看。
