git log --cherry-pick 通过 patch-id 去重，精准识别合并后目标分支独有的实质新增提交：以 + 开头的为真正引入的新变更，= 开头的表示与源分支内容重复已被过滤。
git log --cherry-pick 怎么看合并引入的独有提交
合并操作后，你真正想确认的是：目标分支（比如 main）里有哪些提交是**仅因这次合并才被带入的**，而不是原本就存在于源分支（比如 feature）或其它路径。直接用 git log main ^feature 会漏掉已存在于其它分支的提交，也不反映合并逻辑。
git log --cherry-pick 是专门为此设计的：它基于补丁 ID（patch-id）比对，自动过滤掉内容重复的提交，只显示「实质新增」的变更。
- 执行
git log --cherry-pick --oneline main...feature（注意是三个点），查看feature合并进main后，main独有的提交 - 如果看到某行以
=开头（如= abc1234），说明该提交与feature中某个提交内容完全一致，已被去重 - 以
+开头的（如+ def5678）才是本次合并真正带入的新变更 - 确保两个分支都已本地同步（
git fetch），否则可能漏掉远程新提交
git diff 比较合并前后状态时为什么不能直接 diff 分支名
用 git diff main feature 看到的是两个分支 tip 的快照差异，和「合并操作本身带来的变化」不是一回事——它混入了 feature 自身开发期间 main 也发生的变更，结果不可靠。
正确做法是定位到合并提交本身，再对比它的两个父提交：
GInstall OneClick — 一键安装 GitHub 项目：规划、克隆、安装 Node 依赖、运行开发脚本。适用于想要获取 GitHubNode.js 项目的用户。
- 先找到合并提交：
git log --merges -n 1 main - 假定输出是
abcd123 Merge branch 'feature' into main，运行git show --stat abcd123查看合并引入的具体文件变动 - 若需更细粒度，用
git diff abcd123^1 abcd123^2（^1是第一个父提交，即合并前的main；^2是第二个父提交，即被合并的feature） - 注意：
git diff main feature和git diff main^ feature结果往往不同，后者更接近合并实际效果，但仍有局限
rebase 后合并导致 git log 看不出差异怎么办
如果 feature 在合并前被 rebase 到最新 main，再执行 git merge feature，Git 很可能触发 fast-forward，不产生合并提交。此时 git log --merges 查不到记录，main 和 feature 的提交历史看起来完全重合。
这种情况下，「合并操作」实质上没引入新提交，但你仍可能关心 rebase 过程中是否丢弃/修改过某些提交：
- 检查是否发生 fast-forward：
git merge-base main feature，如果输出等于feature的 HEAD，则说明是 FF 合并 - 还原 rebase 前的
feature引用（如果有 reflog）：git log feature@{1}，再与当前main对比：git log main ^feature@{1} - 用
git range-diff feature@{1} feature直接比较 rebase 前后提交集的变化（Git 2.19+ 支持） - 日常建议：对要合并的分支禁用自动 FF（
git config --global merge.ff false），强制生成合并提交，便于追溯
git show-branch 为什么比 git log 更适合观察分支交汇点
git log 是线性视图，容易掩盖分支结构；而 git show-branch 用字符矩阵直观展示各分支在每个提交上的归属，特别适合快速识别「哪些提交只属于某一分支」以及「合并点位置」。
- 运行
git show-branch main feature，输出中+表示该提交属于对应分支，空格表示不属于 - 交汇处（即某行同时出现
+和!或多个+）就是分支共同祖先或合并点 - 加
--merge-base参数可直接定位最近公共祖先：git show-branch --merge-base main feature - 注意：默认只显示最近 10 个提交，如需更多，加
-a或指定数量，如git show-branch -15 main feature
合并带来的版本差异不是简单的「两头一减」，关键在厘清「变更来源」和「提交归属」。工具选错，看到的只是表象；参数用偏一点，结果就可能倒置。尤其当团队混合使用 merge/rebase、存在多层继承时，单靠 git log 或 git diff 基本不可信。
