git log --pretty=format:是精准控制日志输出的刚需工具，核心在于正确使用%h、%an、%s等占位符，注意双引号包裹、避免空格、区分%an/%cn及%s/%b，并警惕--graph混用时的对齐问题。
git log --pretty 不是装饰性功能，而是排查协作问题、生成发布摘要、快速定位责任人时的刚需工具。用错格式字符串或忽略上下文约束，反而会让输出不可读甚至漏关键信息。
如何用 --pretty=format: 精确控制每行字段
核心是理解占位符含义和组合边界：每个 % 开头的符号代表一个字段，中间不能加空格（除非你真想输出空格），结尾必须用双引号包裹整个字符串。
-
%h是简短哈希（7位），%H是完整 SHA-1（40位）——日常用%h足够，但做 CI 校验或 git bisect 时得用%H -
%an（作者名）和%cn（提交者名）可能不同，比如 PR 合并后%cn是维护者，%an才是原始贡献者 -
%s只取第一行提交信息，%b是完整正文——想看是否带fix:或feat:前缀，用%s；要检查 body 里的Co-authored-by，必须加%b - 颜色支持直接写进 format 字符串：
%Cred%h%Creset %Cblue%an%Creset: %s，但终端不支持 ANSI 的环境（如某些 CI 日志）会显示乱码
为什么 git shortlog 比 git log --pretty=format 更适合统计
git shortlog 是专用聚合命令，不是 git log 的简单别名。它默认按作者分组、自动去重、合并相同标题，而手动用 --pretty=format 拼不出这种逻辑。
- 加
-n按提交数倒序，比自己写 awk 统计%an出现次数快得多 -
--group=trailer:reviewed-by能直接按评审人归类——这依赖 Git 内置的 trailer 解析，git log的 format 不处理 trailer 结构 -
-s输出纯数字摘要（如12 Alice），方便被其他脚本管道消费，git log即使格式再简洁也带固定前缀 - 注意：
git shortlog默认只读 HEAD，要查某次 release 范围，得显式传入v1.2.0..HEAD，否则容易漏掉已合并但未 push 的本地提交
git log --graph 和 --pretty 混用时的对齐陷阱
图形化分支结构时，--graph 会插入 ASCII 线条字符（如 * 、| ），如果 --pretty=format 返回的字符串长度不一致，树形就会错位。
- 避免在 format 字符串里用
%s直接拼接——长提交信息会撑开整行，压扁分支线。稳妥做法是截断：%（左对齐 20 字符，超长省略） -
%cd（提交日期）比%ad（作者日期）更稳定，尤其在 amend 或 rebase 后，前者反映真实合并时间 - 如果同时用
--oneline和--graph，Git 会自动适配格式；但一旦换成自定义format:，就必须手动补上%w(20,4,2)这类换行控制，否则长消息会破坏缩进 - Windows CMD 下
--graph显示异常？不是编码问题，是字体不支持 Unicode 箭头字符，换用git-bash或 Windows Terminal 即可
别把 --pretty=oneline 当万能快捷键
它只是 --pretty=format:"%h %s" 的语法糖，看似省事，实则隐藏了三个硬伤：
- 无法添加颜色、无法截断、无法插入分隔符——想高亮
revert:提交？做不到 - 输出不含邮箱，查不到具体是谁提交的，
git shortlog -e或%ae才行 - 当提交信息含换行符（比如用了
git commit -m "a" -m "b"），--oneline仍只取第一段，但人眼容易误判为“信息不全”，其实只是设计如此 - 真正需要“一行一提交”的场景，比如配合
grep筛选，用--pretty=format:"%h %s"更可控，还能加--abbrev-commit强制简写哈希
格式字符串本质是模板引擎，但 Git 不做运行时校验——写错占位符（比如 %x）不会报错，只会原样输出文字。最保险的方式是先用 git log -1 --pretty=format:"%h %an %s" 验证单条，再放大范围。
