git cherry是专用于查找未合并提交的命令，基于patch内容比对而非commit hash，能准确识别rebase或squash后内容相同但hash不同的提交，输出“+”表示源分支有而目标分支未合并的提交。

git cherry 是查“未合并提交”的专用命令

它不看文件内容改了啥，只回答一个明确问题：某个分支上有哪些提交，还没被合进另一个分支？这和 git diff 或 git log .. 完全不是一回事。

常见错误是用 git log master..feature 代替 git cherry——前者只按 commit hash 判断“是否在路径上”，rebase 或 squash 后的提交即使内容完全一样，也会被当成“新提交”列出来；而 git cherry 基于 patch 内容做比对，能自动跳过这种重复。

• git cherry master feature：列出 feature 中尚未合入 master 的提交（输出带 +）
• git cherry -v master feature：加上提交信息，一眼看出改了什么功能
• 如果输出为空，不代表没差异——先运行 git merge-base master feature 确认两分支有共同祖先，否则 cherry 会直接放弃比对

远程分支对比必须显式 fetch

想查 origin/main 和 origin/feature/login 的未合并提交？不能直接写 git cherry origin/main origin/feature/login——Git 默认只认本地 ref，远程分支名只是“本地缓存的指针”，得先拉下来。

• 执行 git fetch origin（或 git fetch --all），确保 origin/main 和 origin/feature/login 都是最新状态
• 再运行 git cherry origin/main origin/feature/login，这时才真正对比远程分支的当前 HEAD
• 漏掉 fetch 就等于拿你本地上周缓存的 origin/main 去比，结果完全不可信

输出符号含义必须看懂

git cherry 的前三字符不是装饰，是关键判断依据：

openclaw-gitcode-pr-monitor

监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。

下载

• + 表示该提交只存在于后一个分支（即“源分支”），且未合入前一个分支（即“目标分支”）
• - 表示该提交只存在于目标分支，源分支没有——但这个极少出现，除非你反着写了参数顺序
• ? 表示两个分支都有这个 commit hash，但 patch 内容不一致（比如 rebase 后改了 message 或 author，或手动修改过 patch）

注意：? 很容易被忽略，但它意味着“看起来合并过了，其实代码不一致”，CI 或上线前必须人工确认。

跨仓库或无共同历史时别硬用 cherry

如果两个分支压根没交集（比如 fork 出来的独立仓库、或用 git replace / filter-repo 彻底重写过历史），git cherry 会直接报错或返回空——它依赖共同祖先计算 patch 差异。

• 此时应换用 git log --cherry-pick --oneline --left-right A...B，它不依赖 merge base，靠内容哈希匹配
• 或者退一步，用 git diff $(git merge-base A B)..B 手动指定基线，再结合 --stat 快速评估改动范围
• 强行给无历史关系的分支跑 cherry 不仅无效，还会让你误以为“没差异”，这是最危险的错觉

真正难的从来不是命令怎么敲，而是分清什么时候该信 commit hash，什么时候必须信 patch 内容——尤其在多人协作、多环境同步的场景里，这点差之毫厘，后果可能就是线上配置被悄悄覆盖。