AI 总结了 The Git Commands I Run Before Reading Any Code，可以作为参考。
PS：其中部分命令的有效性是建立在提交规范执行良好的基础之上。我过去经手的项目全部没有提交规范。😂

Five git log commands that diagnose a new codebase before you open a single file: code churn hotspots, bus factor, bug clusters, and crisis patterns.

1. 变更热点 列出去年改动最频繁的 20 个文件，榜首常是团队"无人敢碰"的那个。高变更本身不糟，但若叠加"无人愿拥有"，便是代码库拖累的最强信号——每次修改都是补丁叠补丁，小改动的影响范围不可预测。微软 2005 年研究证实，变更率指标比复杂度更能预测缺陷。

git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20

2. 总线因子 按提交数排名贡献者。一人占 60%+ 即为风险；若其已离职半年便是危机。长尾同样关键：30 位贡献者中仅 3 位近一年活跃，说明建造者已非维护者。注意 squash-merge 会压缩作者信息，下结论前需确认合并策略。

git shortlog -sn --no-merges

3. Bug 集群 形态同变更热点，但过滤含 bug 关键词的提交。同时出现在两张列表的文件风险最高：反复出错、反复修补却从未根治。此法依赖提交信息规范。

git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20

4. 提交节奏 按月统计提交数。稳定节奏健康；单月减半常因有人离职；6–12 个月下滑曲线揭示团队失速；周期性尖峰后沉寂则是批量发布模式。这是团队数据，而非代码数据。

git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c

5. 回滚与热修频率 一年中偶发回滚正常；若每几周一次，说明团队不信任部署流程，背后是测试不可靠、缺预发环境或回滚困难。零结果同样值得玩味。

git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'