git log --stat 能显示每次提交修改的文件及增删行数，但默认输出不紧凑；实用组合是 git log --stat --oneline --graph --abbrev-commit --stat-width=120，兼顾可读性与信息密度，且需注意分页器交互（空格翻页、q退出）和 --no-merges 避免合并提交干扰统计。
直接说结论：用 git log --stat 就能显示每次提交修改了哪些文件、增删了多少行，但默认输出不够紧凑，容易被长文件名撑乱；真正实用的组合是 git log --stat --oneline --graph --abbrev-commit，兼顾可读性与信息密度。
为什么 git log --stat 看起来“没反应”或“只显示一行”
这不是命令失效，而是终端分页器（less）在起作用——当输出超过一屏，Git 会自动进入交互式查看模式。你看到的可能是第一屏内容，光标停在底部，但没提示。此时按空格翻页、按 q 退出即可。
常见误操作包括：
- 敲回车只向下滚动一行，误以为卡住
- 没注意到右下角的
END或百分比提示，以为没输出 - 在某些精简终端（如 VS Code 集成终端）中，
less行为异常，可临时加--no-pager绕过：git --no-pager log --stat
git log --stat 的关键参数搭配
--stat 本身只控制“是否显示变更统计”，但实际使用中几乎总要配合其他选项来提升可用性：
Convert Github Repository
下载
适用于以下场景：（1）用户提供 GitHub 仓库 URL 或本地仓库路径，并请求将其转换为其他格式；（2）用户请求导出 GitHub 仓库……
-
--oneline：每条提交压缩成一行，避免作者/时间/哈希占满屏幕，让--stat的文件列表真正“看得见” -
--graph：左侧加 ASCII 分支线，尤其在多人协作或 feature 分支频繁合并时，一眼区分哪些是主线、哪些是 PR 合并点 -
--abbrev-commit：把 40 位 SHA-1 缩成 7 位（如a1b2c3d），否则文件名稍长就直接挤掉统计列 -
--stat-width=120：显式设宽度（单位字符），防止终端自动截断文件路径；不设则依赖当前$COLUMNS，可能在 SSH 或 tmux 中失准
推荐日常使用：git log --oneline --graph --abbrev-commit --stat --stat-width=120
对比 --stat 和 -p：什么时候该用哪个
--stat 是“概览层”，-p（或 --patch）是“代码层”，二者定位完全不同：
- 查“谁改了什么文件”“这次发布动了多少行”——用
--stat；比如上线前快速确认某次git log --stat -n 5是否包含误提交的配置文件 - 查“具体哪几行被改了”“逻辑怎么变的”——必须用
-p；但注意git log -p默认不带--stat，两者不叠加 -
--stat输出里的+/-是行数统计（如src/main.py | 12 +-），不是代码内容；别指望它替代 diff 工具 - 性能上：
--stat比-p快得多，尤其对大仓库或历史久远的提交，-p要解析完整 diff，而--stat只读取元数据
容易被忽略的细节：路径过滤与作者筛选
--stat 支持和其他条件组合，但语法顺序有坑：
- 想看某个目录下的变更统计？把路径放在最后：
git log --stat src/utils/—— 注意末尾斜杠不是必须的，但加了更明确 - 想筛指定作者 + 某个路径？顺序不能错：
git log --stat --author="John" src/；反过来写git log --author="John" --stat src/也行，但src/必须在最后 - 想排除 merge 提交？加
--no-merges，否则--stat会为每个 merge 显示“所有被合并分支的累计变更”，严重误导实际改动量 - Windows 用户注意：
^branch这类排除语法需加引号，如git log --stat ^"main"，否则 cmd 会报错
最常被跳过的其实是 --no-merges：一次 git merge 可能带入几十个提交，--stat 默认全算进去，看起来像“这次改了 200 个文件”，其实只是合了个分支。
