有些文件越改越慢，或者仓库体积突然变大时，我会先看它的历史变化，不急着翻每个提交的完整 diff。环境：Git 2.25+。
git log --follow --stat -- src/assets/data.json
--follow 会尽量跟踪文件改名，--stat 只显示每次提交改了多少行和哪些文件，先定位异常提交会比较快。找到范围后，再看某一次完整改动：
git show --stat --oneline <commit>
git show <commit> -- src/assets/data.json
它适合做初步定位，不适合当精确的文件追踪工具：文件经历复杂拆分或合并时，Git 可能接不上历史。大文件治理时先用这个缩小范围，再结合提交内容判断原因，通常比从头扫完整日志省时间。
补一个小坑：--follow 只对单个文件路径生效，不能直接拿来追踪整个目录。要是改名识别不理想，可以试试显式加 --find-renames，再结合 git show -M <commit> -- <path> 看重命名前后的差异。排查超大二进制文件时，日志只能帮忙定位提交，最终还得看 Git LFS 或历史清理方案。
FinleyLv1#1 补一个小坑：
--follow只对单个文件路径生效，不能直接拿来追踪整个目录。要是改名识别不理想，可以试试显式加--find-renames，再结合git show -M <commit> -- <path>看重命名前后的差异。排查超大二进制文件时，日志只能帮忙定位提交，最终还得看 Git LFS 或历史清理方案。
如果问题可能出现在已经合并的分支，命令前面可以加 --all，不然默认只看当前分支可达的提交：
git log --all --follow --stat -- src/assets/data.json
不过 --all 会把引用能到的分支都扫一遍，仓库很大时会明显变慢。先用 --since 缩时间范围，通常更容易控制输出量。
MukiLv1#2 如果问题可能出现在已经合并的分支，命令前面可以加
--all，不然默认只看当前分支可达的提交：git log --all --follow --stat -- src/assets/data.json不过
--all会把引用能到的分支都扫一遍，仓库很大时会明显变慢。先用--since缩时间范围，通常更容易控制输出量。
还有个容易忽略的点：改名相似度如果和默认阈值不太匹配，可以调一下 -M，比如 git log --follow -M90% --stat -- path/to/file。阈值太低可能把普通大改动误认成改名，太高又可能接不上真实的重命名；大文件或格式化改动后的历史，最好把结果当线索再人工确认。