关键不是全量拉日志，而是聚焦高风险文件高频修改、敏感函数/配置首次引入或删除、跨分支合并带来的权限/逻辑跃迁；需过滤%ae、%cn、%ci等冗余字段，保留%h、%ad、%s，慎用%b，剔除%g?、%d；git diff --name-only需配合--diff-filter=am及白名单过滤，并优先用git log -p -s直接搜索敏感词；多仓库审计应锁定git log origin/main而非--all，避免重复计数。
直接提取 Git 历史中对代码审计真正有用的数据，关键不是“全量拉日志”，而是聚焦三类变更：**高风险文件的高频修改、敏感函数/配置的首次引入或删除、以及跨分支合并带来的权限/逻辑跃迁**。其他字段（如作者邮箱、提交时间毫秒级精度）在审计中基本冗余，强行采集反而拖慢分析、污染结果。
git log --pretty=format 需要过滤掉哪些字段
默认用 git log --pretty=format 容易堆砌一堆审计无关信息，比如 %ae（作者邮箱）、%cn（提交者姓名）、%cI（完整 ISO 时间）——这些在合规审计中既不构成证据链，也无法定位漏洞成因。
- 保留必须项：
%h（短哈希，用于精准回溯）、%ad（作者日期，带时区，比提交日期更能反映真实开发行为）、%s（标题，用于快速筛查“fix auth”“disable ssl”等关键词） - 谨慎使用：
%b（正文）只在启用结构化提交规范（如 Conventional Commits）时才值得提取，否则 80% 是空或“update readme” - 坚决剔除：
%G?（GPG 签名状态）、%d（reflog 引用）——签名不等于代码安全，reflog 是本地操作痕迹，不可审计
git diff --name-only 不足以识别敏感变更
git diff --name-only 只告诉你“改了哪些文件”，但审计真正要问的是：“这个文件里哪行代码把 JWT 密钥硬编码进去了？” 或 “这个 config.yaml 是不是第一次出现 database.password 字段？”
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
- 必须配合
--diff-filter=AM：只抓新增（A）和修改（M）文件，跳过重命名（R）和删除（D）——删除操作需单独用git log --diff-filter=D分析，因为删库跑路比改库更危险 - 对关键路径加白名单过滤：
git diff --name-only HEAD~1 | grep -E '\.(yaml|yml|json|env|py|js)$'，避免被大量 .md 或 .lock 文件淹没 - 真正有效的做法是：先用
git log -p -S 'password' --since="3 months ago"直接搜索敏感词在 patch 中的出现位置，比先列文件再 grep 快一个数量级
多仓库批量审计时 git log --all 的陷阱
对多个仓库执行 git log --all 看似全面，实则埋雷：它会把所有远程分支、stashes、甚至 reflog 都扫进来，导致同一次修复在 feature/xxx 和 origin/main 里被重复计数，审计报告里“高危提交数”虚高 3–5 倍。
- 审计应锁定主干视角：
git log origin/main --since="6 months ago"，忽略所有未合入主线的分支 - 若需对比分支策略，用
git merge-base origin/main origin/dev找最近共同祖先，再以该 commit 为起点分析差异，而非盲目--all - 脚本批量处理时，务必在每个仓库执行前加
git fetch --prune，否则origin/main可能指向陈旧引用，漏掉关键合并提交
审计不是拼数据量，而是找断点。Git 历史里最有价值的那几行，往往藏在一次看似普通的 git diff -U0 输出里——比如某次提交把 verify_ssl=False 加进了 requests 调用，而这条变更在 git log --oneline 里只显示为“update api client”。盯住 diff 内容本身，比任何格式化日志都可靠。
