Git怎么查看合并操作导致的分支版本差异-git-PHP中文网

git log --cherry-pick 通过 patch-id 去重，精准识别合并后目标分支独有的实质新增提交：以 + 开头的为真正引入的新变更，= 开头的表示与源分支内容重复已被过滤。

git怎么查看合并操作导致的分支版本差异

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 也发生的变更，结果不可靠。

正确做法是定位到合并提交本身，再对比它的两个父提交：

One-click installation of GitHub projects

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），强制生成合并提交，便于追溯