git diff branch1 branch2 无输出，主因是两分支最新提交快照内容相同（如cherry-pick导致同内容不同ID），或本地未fetch远程分支、分支名错误、未commit未add改动；应先git fetch，再用git diff origin/branch1 origin/branch2确认真实差异。
直接说结论：用 git diff branch1 branch2 看快照差异，用 git log branch1..branch2 看提交增量——两者目的不同，混用就会漏掉 cherry-pick、rebase 后的“同内容不同 ID”提交。
git diff branch1 branch2 为什么有时没输出？
常见错误现象：git diff main feature 返回空白，但你知道 feature 分支改了代码。
- 分支名拼错，或该分支在本地不存在（比如你只 fetch 过
origin/main，却直接写main）；运行git branch -a确认名字完全一致 - feature 分支确实没 commit ——
git diff比的是两个 提交快照，未git add或未git commit的改动根本不在任何 HEAD 里 - 本地分支陈旧：比如远程已有新提交，但你没
git fetch，此时main指向旧 commit，diff 结果不反映真实差异；应先git fetch origin，再用git diff origin/main origin/feature - 中文路径显示为
\344\270\255\346\226\207？这不是 diff 错误，是终端编码问题；Windows 用户可设git config --global core.quotepath false缓解
git log main..feature 和 git diff main feature 的本质区别
这是最容易混淆的点：git diff 展示「最终文件状态」差异，git log A..B 展示「B 有而 A 没有的提交」。
openclaw-gitcode-pr-monitor
下载
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
-
git diff main feature：把main最新提交和feature最新提交各自生成的文件树做逐行比对，不管中间经过多少次提交、是否 cherry-pick 过 -
git log main..feature：从feature的 HEAD 往回遍历所有祖先，排除掉也能从mainHEAD 遍历到的提交，剩下的就是“feature 独有”的提交列表 - cherry-pick 场景下，同一段逻辑在两个分支都有，但 commit ID 不同 →
git diff显示无差异（内容一样），git log main..feature却会列出那个 cherry-pick 出来的提交（ID 不同，算“独有”） - 想看“哪些文件被改过但不刷屏”，加
--name-only；想粗略评估规模，加--stat；二者都不受.gitignore影响，已跟踪的忽略文件仍会出现在结果中
远程分支差异必须用 origin/xxx 格式
团队协作中，你真正要确认的不是“我本地的 main 和 feature 差在哪”，而是“远程仓库的 main 和 feature 差在哪”。
- 本地分支可能长期未更新，
git pull会自动 merge，污染历史；更安全的做法是只用git fetch同步远程引用 - 正确命令是：
git fetch origin && git diff origin/main origin/feature或git log origin/main..origin/feature - 如果
git branch -r里看不到origin/feature，说明它没被 fetch 下来；可用git ls-remote --heads origin | grep feature确认远程是否存在，再执行git fetch origin feature - CI 脚本中常结合管道过滤，例如：
git diff --name-only origin/main origin/feature | grep "^src/api/"，判断是否需要触发 API 测试
复杂场景别硬扛，换 range-diff 或图形工具
当分支经历过 rebase、squash、cherry-pick 多次后，单纯靠 git diff 或 git log 很难理清逻辑关系。
-
git range-diff origin/main...origin/feature（注意是三点）可对比两组提交序列的语义等价性，比如 rebase 前后、PR 修改前后；它会告诉你“原第2个提交现在对应新序列的第3个，且内容基本一致” - VS Code 内置 GitLens、JetBrains IDE 的 Log 视图、GitHub PR 页面的三点 diff（
base...head）都默认展示 merge base 到 head 的差异，比两点 diff 更贴近“这次 PR 真正引入了什么” - 不要依赖
git diff --submodule默认行为——子模块差异默认不递归展开；真要检查，得显式加--submodule=diff，否则看到的只是 submodule commit ID 变更
最常被忽略的一点：Git 所有 diff 命令都是基于对象哈希计算的，没有“语义理解”能力。哪怕你只是改了个空格、调换了两行顺序，只要 commit ID 变了，git log A..B 就会把它当新提交；而 git diff 虽能忽略空格（加 -w），但无法识别“逻辑等价的重构”。实际排查时，得根据目标选命令，而不是凭直觉敲完回车等结果。
