← #789

阅读代码之前我会先运行的 Git 命令

文章摘要

Ally Piechowski 于 2026 年 4 月 8 日发表的这篇博文介绍了五个 Git 命令，它们能在你打开任何一个源代码文件之前，就帮你诊断出一个代码库的”痛点”所在。作者认为，在接手一个新项目时，与其直接钻进代码细节，不如先用这些命令做一次快速的”健康体检”。

第一个命令：找出变更最频繁的文件。 使用 git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20 可以列出过去一年内改动次数最多的 20 个文件。排在最前面的文件几乎总是别人会警告你”小心那个文件”的那个。一个文件如果同时具有高变更率和高 bug 率，就是你最大的风险点。

第二个命令：了解谁构建了这个项目（Bus Factor）。 通过 git shortlog -sn 对每个贡献者按提交次数排名，如果一个人的提交量占了 60% 以上，那就是你的”巴士系数”——如果这个人被巴士撞了，就没人懂这段代码了。作者建议还要检查最近六个月的窗口，如果核心贡献者在近期没有出现，应该立即标记为风险。

第四个命令：团队的”救火”频率。 通过 git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback' 检查回滚和紧急修复的频率。一年内出现几次是正常的，但如果每隔几周就有一次回滚，说明团队不信任自己的部署流程。

第五个命令：项目是在加速还是衰亡？ 通过比较不同时间段的提交频率，判断项目的活跃度趋势。

作者总结说，这五个命令只需几分钟就能运行完，虽然不能告诉你一切，但你会知道应该先读哪些代码，以及读的时候要注意什么。这篇文章被 GIGAZINE 等多家媒体转载，引发了广泛讨论。

HN 评论精华

Jujutsu (jj) 替代方案：有评论者分享了使用 Jujutsu 版本控制系统实现类似分析的命令，例如 jj log --no-graph -r 'ancestors(trunk()) & committer_date(after:"1 year ago")'。评论者认为 Jujutsu 的 Git 兼容策略很聪明，Mercurial 和 Fossil 因为试图完全替代 Git 而失败了。
对 Bus Factor 指标的讨论：一些评论者指出，提交次数并不总是衡量知识集中度的最佳指标。有人可能做了大量小型格式化提交但并不真正理解系统，而另一个人可能只有少数关键提交却掌握了核心架构。建议结合代码审查记录和变更行数来综合判断。
自动化工具推荐：多位评论者推荐了将这些命令打包成自动化工具的项目，如 GitNStats、busfactor 分析器等，认为这些命令应该集成到 CI/CD 流水线中，作为项目健康度的持续监控指标。
实际经验分享：有开发者分享了在大型企业代码库中使用类似方法的经验，发现最频繁变更的文件往往是配置文件和 ORM 模型定义文件，这些文件的高变更率通常反映了需求变动而非代码质量问题，需要结合上下文解读。
对”救火频率”的补充：有评论者建议除了搜索 revert 和 hotfix 关键词外，还应该检查深夜和周末的提交模式，因为非工作时间的提交往往意味着紧急问题。同时建议关注提交消息中的情绪词汇（如 “finally”、”hack”、”workaround”）来发现技术债务的迹象。