git show 看不到 cherry-pick 引入的真实差异，因其仅显示该提交在原分支的自身变更；应使用 git diff head^..head（或具体哈希）对比其在目标分支上的实际父提交，才能看到真正新增内容。
git show 为什么看不到 cherry-pick 引入的差异？
因为 git show 默认只显示该提交自身的变更（即它在原分支上产生的 diff），而 cherry-pick 是把一个提交“复制”到另一条历史线，其 parent 关系已改变——Git 不会自动关联原始上下文。你看到的可能是空 diff 或与预期不符的改动。
真正要查的是：这个被挑过来的提交，在目标分支上「实际引入了哪些新增内容」，也就是它相对于当前分支前一个状态的净变化。
- 用
git show <commit-hash></commit-hash>只能看该提交对象本身的 tree 差异，不反映 cherry-pick 后的语义差异 - 如果目标分支已有部分相同修改（比如上游已合入类似 patch），
git show会照常输出全部变更，但实际生效的可能只是其中几行 - 正确思路是：把 cherry-pick 提交和它在目标分支上的直接 parent 做比较
用 git diff HEAD^..HEAD 查当前提交引入的差异
这是最直接有效的方式，前提是 cherry-pick 后还没做其他提交。此时 HEAD 就是你刚挑进来的那个提交，HEAD^ 是它的父提交（即 cherry-pick 的 base）。
执行：
git diff HEAD^..HEAD
就能看到这个 cherry-pick 在当前分支上「真正新增了什么」。
- 如果 cherry-pick 发生在合并之后（比如
git cherry-pick A B连续挑两个），需替换为具体哈希：git diff <parent-commit-hash>..<cherry-picked-commit-hash></cherry-picked-commit-hash></parent-commit-hash> - 注意不要用
...（三点语法），它走的是 merge-base 路径，对单个 cherry-pick 反而可能绕远 - 加
--stat快速看改了哪些文件：git diff --stat HEAD^..HEAD
如何定位 cherry-pick 提交的原始 parent？
当 cherry-pick 后又做了多次提交，HEAD^ 就不是它的 parent 了。这时得先找出这个提交在目标分支上的真实父节点。
方法一：查 reflog 看它被 pick 时的上下文
git reflog -n 20 | grep cherry-pick
找到类似 abc1234 HEAD@{5}: cherry-pick: fix user timeout handling 的记录，再用 git show HEAD@{6} 确认前一个状态。
- 更稳的方式是用
git log --oneline --decorate --simplify-by-decoration -n 20，观察 cherry-pick 提交前后最近的非-cherry-pick 提交 - 如果该 cherry-pick 是从另一个远程分支挑的，原始 parent 很可能不在本地历史里，此时必须依赖
git merge-base找共同祖先，再人工比对 -
git show --pretty=raw <commit></commit>能看到parent字段，但那是它在原分支的 parent，不是目标分支上的逻辑 parent
cherry-pick 后 diff 异常的常见原因
有时 git diff <parent>..<cherry-picked></cherry-picked></parent> 输出大量看似无关的改动，甚至冲突标记残留，这不是 Git bug，而是 cherry-pick 过程中发生的隐式调整。
- 目标分支代码结构已变（如函数重命名、文件拆分），Git 应用 patch 时做了行偏移匹配，diff 显示的是「应用后结果」vs「应用前快照」，而非原始 patch 内容
- 如果有冲突并手动解决过，
git commit --no-edit生成的提交会包含所有解决后的状态，diff 自然包含那些手修部分 - 使用
-x参数 cherry-pick 会在提交信息末尾追加(cherry picked from commit ...)，但不影响 diff 内容；而-m 1（用于合并提交）容易误用，导致 parent 指向错误，diff 完全失真
真正需要对比的，永远是「cherry-pick 后目标分支的实际状态」和「cherry-pick 前目标分支的状态」，而不是它来自哪里。
