合并前必须用 git diff main...feature/login（三点语法）检查功能分支独有变更，而非 git diff main feature/login（两点），因前者基于最近公共祖先对比，准确反映该分支实际改动，避免引入无关变更。
合并前必须确认两个分支的差异是否符合预期，否则可能把不该带的修改一起合进去。直接 git merge 是最危险的操作起点。
用 git diff branchA branchB 看“从 A 到 B 要改什么”
这是最基础也最容易误解的命令。注意：git diff main feature/login 表示“如果要把 main 变成 feature/login，需要做哪些改动”，即展示 feature/login 相对于 main 的新增/修改/删除内容。
- 输出中
a/对应main（旧版），b/对应feature/login（新版） - 默认只显示文本变更，不显示重命名或删除状态 —— 加
--name-status才能看到M（修改）、A（新增）、D（删除）标记 - 如果分支历史有合并提交，
git diff仍只比快照，不考虑拓扑路径 —— 它不会自动找最近公共祖先（merge base）
用 git diff main...feature/login（三个点）看“这个分支独有的变更”
三个点语法会自动计算 main 和 feature/login 的最近公共祖先（merge base），然后对比该祖先与 feature/login 的差异。这才是真正反映“这个功能分支自己做了什么”的安全视角。
- 等价于先运行
git merge-base main feature/login，再执行git diff <merge-base> feature/login</merge-base> - 适合用于 Code Review：它过滤掉了
main后续合并进来的其他分支变更，避免噪声干扰 - 如果你在
feature/login分支上执行git diff main...，可以省略第二个参数（Git 自动补全为当前分支）
VSCode 里点两下就能比，但得选对模式
按 Ctrl+Shift+P 输入 Git: Compare Branches，选完源/目标分支后，VSCode 会调用 git diff 并渲染图形化视图。但要注意：
- 它默认使用两个点语法（
branchA..branchB），和git diff branchA branchB行为一致 - 右键分支名 → “Compare with Branch” 也是同样逻辑，不是三路比较
- 想获得语义更干净的对比，建议先在终端跑一遍
git diff main...feature/login --stat确认文件范围，再点开具体文件查看行级差异 - 装 GitLens 后，可直接打开
Branch Comparison View，它底层会帮你算 merge base，并高亮提交偏移量，比原生 UI 更可靠
别跳过 --stat 和 --name-only 这两个参数
一上来就看大段 diff 容易迷失。先快速扫描“改了哪些文件”，再决定是否深入某几个关键文件：
-
git diff main...feature/login --stat：列出所有变更文件 + 增删行数，一眼识别是否意外动了package.json或配置文件 -
git diff main...feature/login --name-only：只列文件路径，适合配合grep过滤，比如grep "\.ts$" | xargs code快速打开所有 TypeScript 变更 - 加
--no-commit-id --no-index没意义 —— 这俩是给非 Git 项目用的，分支对比时 Git 已经知道上下文
真正的坑不在命令写错，而在于误以为 git diff A B 和 git diff A...B 是一回事。后者才真正对应“这个分支的独立工作成果”，前者只是两个快照的机械差集 —— 尤其当 main 已经向前走了很多提交时，差别会非常大。
