应使用 git diff main...feature/login（三点语法）而非 git diff main feature/login，因后者仅对比两分支最新提交快照，会混入无关改动；三点语法自动定位共同祖先，精准显示该分支独有改动。
git diff feature main 直接对比两个分支最新提交
这是最常用也最容易出错的起点：很多人以为 git diff feature main 就是“把 feature 分支所有改动和 main 比”，其实它只比两个分支 tip（即各自最新 commit）之间的差异，不关心谁 merge 过谁、有没有共同祖先。
常见错误现象：
- 输出大量看似“无关”的修改，其实是两个分支从分叉点之后各自独立演进导致的
- 误以为某文件在
feature中被删了，实际只是main新增了它
正确用法建议：
- 先确认分叉点：
git merge-base feature main，得到共同祖先 commit ID - 再用
git diff $(git merge-base feature main) feature查看feature相对于分叉点的净变更 - 如果只想看“
feature合入main会带来什么”，应该用git diff main...feature（三点语法），它自动找 merge-base 并只显示feature独有提交的变更
git log --cherry-pick --oneline <code>main..feature 找出未合并的提交
当你需要知道“feature 里哪些提交还没进 main”，git diff 不够用 —— 它只告诉你代码变了，不告诉你哪次提交变的。
使用场景：
- 准备 PR / MR 前快速核对变更范围
- 回滚时定位具体要 revert 的 commit
- 同步分支前确认是否遗漏了关键修复
注意参数差异：
-
main..feature（两点）：列出所有在feature但不在main路径上的提交（含已 cherry-pick 过的） -
main...feature（三点）+--cherry-pick：排除内容重复（哪怕 commit ID 不同）的提交，更接近“语义上未合并” - 加
--no-merges可跳过 merge 提交，避免干扰
VSCode / IDEA 里点两下就出差异，但默认不显示逻辑变更
图形化工具省事，但容易掩盖关键信息。比如 IDEA 默认启用“忽略空格”，VSCode 的 diff 视图默认不展开函数签名上下文 —— 这些设置让视觉上“干净”，却可能漏掉真实影响。
容易踩的坑：
- 在 IDE 里右键 “Compare with Branch” 后看到“无差异”，结果 CLI 执行
git diff -w发现一堆空格变更 —— 是 IDE 默认开了-w，而你团队约定不允许空格污染 - IDE 显示某方法“仅修改一行”，但没高亮该行属于哪个函数，结果上线后发现改的是同名重载方法中的错误一个
- VSCode 的
git diff feature/login --stat输出只列文件名和行数，但你真正需要的是“哪些业务逻辑块被动过了”，得切到 Terminal 补一句git log -p -n 5 feature/login -- src/service/
git difftool -t vimdiff <code>HEAD~3 HEAD 适合逐文件确认敏感修改
当你要审核一段加密逻辑、权限判断或支付回调处理，不能只信 git diff 的文本输出 —— 需要人工逐行盯，且希望保留上下文（比如函数头、注释、相邻 if 分支）。
为什么不用纯 CLI diff：
-
git diff默认只显示 +/- 行，没有当前文件完整结构 - 长文件中分散的几处修改，靠肉眼滚动容易漏关联逻辑
- 某些 diff 工具（如
meld）支持折叠 unchanged blocks，vimdiff支持跳转到下一个 diff hunk（]c）
实操建议：
- 提前配好
git config --global difftool.vimdiff.cmd 'vimdiff "$LOCAL" "$REMOTE"' - 避免直接
git difftool HEAD~3 HEAD—— 它会打开每个变更文件，容易迷失。改用git difftool HEAD~3 HEAD -- path/to/file.go锁定目标 - 如果用 VSCode，安装 GitLens 插件后，右键文件选择 “Git: Compare With Previous Version”，它比原生 diff 多一层 AST 感知，能标出“这个变量名被重命名了”，而非只标“这一行替换了”
对比分支差异这件事，核心不是“怎么看到不同”，而是“看到的差异是否反映真实语义变化”。commit ID、分支名、merge-base 这些都是壳，真正要抓的是“这段代码逻辑上从 A 变成了 B”，而这个判断往往需要结合上下文、测试结果和人脑推理 —— 工具只负责把壳剥开。
