git diff branch1..branch2 显示 branch1 相对于 branch2 的变更，即 branch1 有而 branch2 无的改动；顺序决定基准，双点语法明确表达“从 branch1 可达但 branch2 不可达”的提交差异。
git diff 比较两个分支的提交差异
直接用 git diff branch1..branch2 就能看到 branch1 和 branch2 之间所有未合并的变更。注意双点（..）不是打错了——它表示“从 branch1 可达、但 branch2 不可达”的提交所引入的改动。
常见错误是写成单点：git diff branch1 branch2，这其实等价于双点语法，但容易让人误以为顺序无关；实际顺序决定“谁减谁”：结果是以 branch2 为基准，显示 branch1 相对于它的新增/修改/删除。
- 想看 feature 分支比 main 多了什么？用
git diff main..feature - 如果只关心某几个文件的差异，末尾加路径过滤：
git diff main..feature -- src/utils.js - 加上
--name-only只列出变动的文件名，适合快速扫描范围
git log 查看分支间有哪些提交没同步
git log main..feature 列出在 feature 有、但 main 没有的提交，也就是 feature 独有的改动历史。反过来写 git log feature..main 就是 main 独有的提交（比如线上 hotfix）。
别依赖图形化工具默认视图——很多 GUI 会自动隐藏 merge commit 或折叠共祖，导致漏掉关键同步点。命令行输出更可靠，尤其加 --oneline --graph --all 能看清分叉与合并结构。
- 加
--cherry-pick可排除已被 cherry-pick 过的提交（避免重复计算） - 如果分支长期未同步，
git log --merges main..feature能单独揪出 merge commit，判断是否已合入
git merge-base 定位最近共同祖先
两个分支差异大时，直接 diff 可能包含大量无关变更（比如一方 rebased 过）。这时先用 git merge-base main feature 找到最近共同祖先 commit，再以它为基准比较：git diff $(git merge-base main feature)..feature，结果更聚焦“真正新增”的内容。
这个步骤常被跳过，但对 rebase 后的分支或 fork 出来的长期维护分支特别关键——否则 diff 会把 base 分支的历史重放也当“差异”算进去。
-
git merge-base --is-ancestor main feature可判断 main 是否已是 feature 的祖先（即 feature 是否已完全包含 main） - 如果返回空，说明不是；返回 0 表示是，可避免无意义的 diff
diff 结果里看到大量二进制文件或乱码？检查 .gitattributes
图片、PDF、压缩包这类二进制文件默认不显示 diff 内容，只提示 Binary files a/file.png and b/file.png differ。这不是 bug，是 Git 的默认行为。
若需对比某些二进制格式（如 .docx），得提前配置 .gitattributes 告诉 Git 如何处理，例如：
*.docx diff=word，再配好相应的 textconv 工具。但绝大多数场景下，真没必要——版本控制二进制文件本身就有风险，优先考虑用 LFS 或换文本方案。
另一个常见干扰是换行符（CRLF vs LF）导致 diff 显示整行变化。用 git config --global core.autocrlf true（Windows）或 false（macOS/Linux）统一策略，比每次 diff 都加 --ignore-space-at-eol 更治本。
