git log -S 搜索字符串在提交diff中的净增减变化，而非全文匹配；-G 支持正则匹配代码行；二者均需显式指定路径，且默认不跨分支、不追踪重命名。
git log -S 搜索的是“变更引入的字符串”，不是任意文本
很多人以为 git log -S 能像 grep 一样全文搜提交信息或代码任意位置，其实它只匹配「某次提交的 diff 中，该字符串在新增行出现次数 ≠ 删除行出现次数」——也就是这个字符串是这次变更「净增加」或「净删除」的。比如你改了一行 foo = 1 → bar = 1，-S foo 不会命中，因为 foo 只在删除行出现一次，新增行为 0；但 -S bar 会命中。
常见错误现象：git log -S "logger.info" 找不到刚加的日志语句，其实是那条语句被加在已有函数末尾，而该函数之前就含 logger.info，导致新增/删除行数相等，被过滤掉了。
- 想确认是否真有净变化，加
-p看原始 diff：git log -S "myFunc" -p - 区分大小写默认开启，如需忽略，加
-i（但注意：这仅影响字符串比对，不影响正则） - 不支持通配符或模糊匹配，
-S "api*"会被当作字面量搜索api*字符串
用 -G 替代 -S 实现“代码行级正则搜索”
当你要找的是「某行代码是否出现过」，而不是「某字符串是否因这次提交而增减」，应该用 -G。它对每个 commit 的 diff 行做正则匹配，只要新增或删除的任一行满足正则，就列出该 commit。
使用场景：搜索所有加过 console.log、删过 TODO、或修改过带 password 的赋值语句。
-
git log -G "console\.log" --oneline（注意点要转义） -
git log -G "^ *if.*{" --oneline找所有新增/删掉的 if 开头行 -
-G默认启用正则，不加-i也是大小写敏感；加-i后整个正则忽略大小写 - 性能影响：正则比字面量慢，尤其在大仓库中遍历历史时，建议配合
--since="2 weeks ago"或指定分支限制范围
搜索范围必须显式限定路径，否则可能漏结果
git log -S 和 -G 默认在整个仓库历史中扫描，但如果你只改了 src/utils/ 下的文件，而没限定路径，Git 仍会检查所有目录的 diff —— 这本身没错，但容易误判：比如你在 test/ 里删了一行含目标字符串的代码，它也会被算作一次「净删除」，从而出现在结果里，干扰主线逻辑追踪。
更关键的是，Git 不会自动推断你关心哪部分代码。不加路径，-S 就可能返回几百个无关提交。
- 限定单文件：
git log -S "API_TIMEOUT" -- src/config.js - 限定目录：
git log -G "axios\." -- src/services/ - 多个路径用空格分隔，不要用逗号或引号包裹路径列表
- 路径必须存在且拼写准确；错写成
srvc/会导致命令静默失败（返回空，无报错）
别依赖 --all 或 --branches 默认覆盖全部，先确认当前视图边界
执行 git log -S "token" 时，Git 默认只查当前分支可到达的提交（即 HEAD 及其祖先）。如果你在 main 上运行，但目标提交在 feature/auth 分支上且尚未合并，它根本不会出现。
有人习惯加 --all，以为这样最保险，但要注意：--all 包含所有 refs（包括已删的本地分支、stale remote-tracking branches），结果可能混入大量陈旧或实验性提交，反而难定位。
- 明确要查哪个分支：用
git log -S "initDB" origin/main查远程主干 - 查所有本地分支：用
git log -S "v2" --branches（比--all更干净） - 查某次合并前的历史：用
git log -S "retry" HEAD...origin/main（三点语法） - 加
--merges可进一步缩小到仅合并提交，适合排查集成问题
最常被忽略的一点：-S 和 -G 对重命名后的文件无效，除非你额外加 --follow，但 --follow 只支持单文件且不能和路径通配一起用。所以如果目标代码经历过文件移动，得先用 git log --follow --oneline old_name.js 找到重命名点，再分段用 -S 搜索。
