应使用 git diff HEAD^ HEAD 查看本次合并带入的所有变更；若为快进合并，则用 git diff HEAD~2 HEAD 或 git merge-base 定位共同祖先后对比，避免误含无关改动。
git diff 比较两个 commit 之间的差异
合并后想看改了哪些代码，最直接的方式是用 git diff 对比合并前后的提交。比如你刚执行完 git merge feature/login，当前 HEAD 是合并后的 commit，而 HEAD^（或 HEAD~1）通常指向合并前的主干 commit（即第一个父提交），HEAD^2 指向被合并进来的分支 tip。
常见错误是直接运行 git diff HEAD，这没意义——它对比的是工作区和 HEAD，不是合并引入的变更。应该明确指定范围：
-
git diff HEAD^ HEAD：查看本次合并带入的所有变更（等价于git show HEAD的 patch 部分） -
git diff HEAD^2 HEAD：只看被合并分支（如 feature/login）相对于合并点的改动 - 如果合并是快进（fast-forward），
HEAD^不存在，此时要用git diff <commit-hash-before-merge> HEAD</commit-hash-before-merge>
git log --cherry-pick 找出真正新增的提交
当合并涉及大量提交，且上游已存在部分相同改动（比如提前 cherry-pick 过某些修复），git diff 会把重复内容也列出来，干扰判断。这时用 git log --cherry-pick --oneline 更准。
它会标记哪些提交在两边都存在（用 =），哪些是真正新增的（用 +）。例如：
git log --cherry-pick --oneline main...feature/login
注意三点：
- 必须用三点语法（
main...feature/login），表示“在任一分支上但不在共同祖先之后”的提交 -
--cherry-pick依赖 patch ID（内容哈希），对重排、空格调整敏感；若代码被格式化过，可能误判为“新增” - 不显示具体代码行，只定位到提交粒度，需配合
git show <commit>看细节
git merge-base 定位正确的比较基线
多人协作中，HEAD^ 不一定可靠——比如你执行的是多头合并（git merge A B C），或者用了 --no-ff 但历史被重写过。这时候手动找最近共同祖先更稳妥。
GInstall OneClick — 一键安装 GitHub 项目：规划、克隆、安装 Node 依赖、运行开发脚本。适用于想要获取 GitHubNode.js 项目的用户。
用 git merge-base 确定基线 commit：
-
git merge-base main feature/login：输出两个分支最近的共同祖先 commit hash - 再用
git diff <hash> feature/login查看该分支从基线开始的所有改动 - 如果合并后发现冲突已解决但逻辑不对，可对比
git diff <hash> HEAD，排除掉 merge commit 自身的解决逻辑（如自动插入的
别依赖图形工具自动选的“base”，IDE 内置 diff 有时默认用 index 或工作区，容易漏掉暂存区里未提交的中间状态。
处理合并冲突残留和 whitespace 差异
合并后运行 git diff 经常看到大量空格、换行符或缩进变化，这不是业务逻辑差异，而是编辑器或 pre-commit hook 自动格式化导致的。这类噪音会掩盖真实问题。
临时过滤它们：
-
git diff -w：忽略所有空白字符变化（慎用，可能隐藏有意义的缩进修复） -
git diff --ignore-space-change：只忽略空格数量变化，保留换行和 tab 差异 -
git diff -U0：减少上下文行数，聚焦变更本身，避免被冗长的函数头/注释干扰
真正关键的是：检查前先确认团队是否统一了 .editorconfig 和 pre-commit 格式化规则。否则每次合并都要人工分辨哪行是功能修改、哪行是自动加的分号。
