git log -p 比 git diff 更适合查历史泄露，因其能逐条展开所有提交的补丁内容，覆盖已被删除但曾存在的敏感凭证，而 git diff 仅比对工作区或暂存区，遗漏历史快照。

为什么 git log -p 比 git diff 更适合查历史泄露？

因为敏感凭证常藏在已提交但后来被删掉的代码里，git diff 只比对工作区或暂存区，漏掉历史快照。git log -p 能逐条展开每次提交的补丁内容，覆盖所有可能埋雷的位置。

实操建议：

• 用 git log -p --all --grep="" 配合 grep 做关键词扫描，比如 git log -p --all | grep -i "password\|apikey\|secret"
• 加 --since="3 months ago" 限制时间范围，避免全量扫描拖慢脚本
• 注意 --all 包含所有分支和 reflog，但不包含 stash；如需查 stash，额外加 git stash list -p | grep -i ...
• 某些凭证（如 Base64 编码的 token）会逃过明文匹配，后续得加解码逻辑，别只靠字符串匹配

怎么用 git ls-files 避免扫描二进制或忽略文件？

直接 git grep 扫整个工作区容易误报：.zip、.png、node_modules 下的第三方库都可能含 “password” 字样，但跟项目无关。

正确做法是先筛出真正受版本控制的文本文件：

• 用 git ls-files --exclude-standard 获取干净的 tracked 文件列表
• 过滤后缀：git ls-files --exclude-standard | grep -E "\.(js|py|java|env|yml|json|xml|ts)$"
• 再对这些文件做行级扫描：xargs -I{} sh -c 'grep -n -i "aws_secret.*[0-9a-zA-Z]" {} 2>/dev/null'
• 跳过 vendor 目录：git ls-files --exclude-standard | grep -v "/vendor/" | grep -v "/node_modules/"

git rev-list 如何精准定位首次引入敏感词的提交？

发现泄露后，光知道“有”不够，得快速定位谁、什么时候、在哪一行加的——这对追责和修复最关键。

Conventional Git

Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。

下载

用 git rev-list 结合 git blame 是最稳路径：

• 先用 git rev-list --all --grep="API_KEY" 找到含关键词的 commit hash
• 再用 git show <code>COMMIT_HASH --name-only 看改了哪些文件
• 对具体文件执行 git blame -w -M -C <code>FILE_PATH | grep -i "secret"，-w 忽略空格变更，-M/-C 支持移动/复制检测
• 注意：如果该行后来被修改过但关键词没删，git blame 显示的是最后一次修改者，不是原始引入者；必须配合 git log -S

为什么正则写成 aws_[a-z]+_key 比 aws.*key 更安全？

宽泛正则会大量误报：比如注释里写 “aws usage key is deprecated”，或者变量名 aws_backup_key_path 是合法字段，但匹配 aws.*key 就报警，导致脚本不可信。

推荐策略：

• 用单词边界锚定：\baws_[a-z]+_key\b，排除中间夹杂其他字符的情况
• 区分环境：^SECRET_KEY=（.env 文件开头）、"token":\s*"[a-zA-Z0-9+/=]{20,}"（JWT-like token）
• 排除常见误报模式：加 grep -v "example\|test\|demo\|placeholder"
• 硬编码密钥往往带固定格式，比如 AWS access key 是 AKIA[0-9A-Z]{16}，比泛搜 “aws_access_key” 更准

真正难处理的是拼接生成的密钥（如 os.getenv("KEY_PREFIX") + "_prod"），这种静态扫描无能为力，得靠 pre-commit hook + 动态测试兜底。