git log --oneline仅显示简洁摘要，无法查看差异；需加-p参数（即--patch）显示每次提交的完整文件改动，配合-n可指定条数，如git log -p -n 3。
git log --oneline 看不清差异，该加什么参数
只看提交摘要根本没法判断改了啥，git log --oneline 本质只是压缩版日志，不带变更内容。真要分析差异，得让 git log 把 diff 也带上。
最直接的是加 -p（即 --patch），它会为每个提交显示完整的文件改动。但注意：默认只显示最近一次提交的 patch，想看多条就得配合 -n，比如 git log -p -n 3 查最近三次的完整差异。
- 如果只想看某次提交的 diff，用
git show <commit-hash></commit-hash>更精准，它等价于git log -p -n 1 <commit-hash></commit-hash> -
-p输出量大，终端容易刷屏，建议搭配| less或用 IDE 内置 Git 工具查看 - 别用
git log -p --all直接扫全量历史——分支多、提交密时，可能卡死或输出几万行
对比两个版本之间所有改动用 git log .. 还是 ...
这是最容易混淆的点：.. 和 ... 行为完全不同。
git log A..B 表示“能从 B 到达、但不能从 A 到达的所有提交”，也就是 B 相对于 A 的新增提交（单向差集）。而 git log A...B 是“能从 A 或 B 到达、但不能同时从两者到达的提交”，即 A 和 B 的共同祖先到各自顶端的对称差集（常用于合并前看双方各自改了啥）。
- 日常比版本差异，比如 release/v2.1 和 main 分支，用
git log release/v2.1..main查 main 新增了哪些提交 - 想看两个分支各自独立改了哪些文件（尤其合并前评估冲突风险），用
git log --name-only release/v2.1...main，再加--cherry-pick可过滤掉已合并的提交 - 误写成
git log A..B..C会报错；A...B...C语法虽不报错，但结果不符合直觉，避免嵌套使用
git log --stat 显示的文件列表不准，为什么
--stat 只统计被提交修改过的文件路径，但它不区分“内容变更”和“仅属性变更”（如 chmod）、也不反映重命名/复制这类操作的真实影响范围。
更关键的是：如果某次提交里某个文件先被修改、又在同一次提交中被 git reset 撤回（暂存区清空但工作区仍脏），--stat 仍会把它列为“已更改”，因为 Git 日志记录的是 commit 对象快照，不是操作过程。
- 确认真实改动请用
git show --stat <commit></commit>，它比git log --stat -n 1少一层抽象，结果更可靠 - 需要知道某文件在哪些提交里被改过？用
git log --follow -p -- <file-path></file-path>，--follow能跨重命名追踪 -
--stat默认截断长文件名，加--stat=1000（数字为宽度）可展开，但终端宽度不够时依然会折行
用 git log 分析大仓库性能太慢，怎么提速
当仓库提交超 5 万、文件数过万时，git log 默认扫描整个 reflog 和所有引用，耗时飙升。这不是网络或磁盘问题，是 Git 历史遍历算法本身的开销。
- 加
--no-merges跳过合并提交（它们本身不带新代码，纯连接作用），速度常提升 30%–50% - 限定路径：
git log --oneline -- src/utils/比扫全库快一个数量级，Git 会跳过无关目录的 tree 遍历 - 禁用文本搜索：
--grep、-S（pickaxe）这类参数会让 Git 解包每个 commit 的全部 blob，务必慎用；真要搜内容，先用git rev-list缩小范围再git grep - Windows 上用 MSYS2 或 WSL 运行比 Git for Windows 快，因后者默认启用太多兼容层
真正棘手的是二进制大文件混在历史里——git log --all --oneline 会尝试加载每个 commit 的完整对象，哪怕你没要 diff。这种场景，要么用 git filter-repo 彻底清理，要么接受“查历史就得慢”这个事实。
