今天在某个科技杂志上，看到有篇文章，我觉得有必要收藏一下。

就是作者 Ally Piechowski ，在阅读任何代码之前都要运行的 5 条 Git 命令。

当然，这里的代码是由 Git 管理的那种。

我觉得这个思路很有意思。现在 AI 时代了，把这个作为我们辅助阅读代码的 SKILL 的一部分，也不失是一种好办法。因为我最近学 bash ，研究 agent 怎么使用复杂的 bash 语法来操控我们的计算机，眼睛走火入魔，今天一眼看到这个文章，就双目发亮！

原文在这里： https://piechowski.io/post/git-commands-before-reading-code/

我来解释一下这 5 句都是什么，都该怎么用。原文写的很复杂，我来简化一下。

运行完，能了解几个问题：作者都是谁？哪片儿问题多？团队是否严谨？然后就心有成竹了。可以让你接下来阅读有条不紊一点，反正总比漫无目的地闲逛好多了。

第一句，看看哪块区域变动很频繁

代码：

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

首先前面的 【1 year ago】把过去一年的 Git 记录写出来。

之后 【--name-only】是只显示文件名。【--format=format:】隐藏日期和提交人。

这句命令干什么的呢？

就是找出过去一年被提交和修改最频繁的 20 个文件！

过去一年中改动最频繁的20个文件。排在最顶端的那个文件几乎总是人们会提醒我的那个。“哦，那个文件啊，大家都怕碰它。”

意思就是要提高警惕，最危险的代码通常是：改得频繁、经常出错、没人敢负责 的那个。

作者说要提取前 5 个文件，与下方介绍的几个 BUG 高发处对比，找到最大的风险源。

第二句，贡献人（提交人）是谁

代码

git shortlog -sn --no-merges

这句很简单。就是把提交人按照次数罗列出来。

输出就像这种样子：

120 张三 
85 李四 
20 王五

这个很重要。

如果某个人占比大于 60% ，就是一个风险。如果这个人还离职了（或者最近 6 个月没提交），那就相当有危险，需要重视这个问题。

第三句，BUG 高发地

代码

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

就是找到哪些文件，经常出现在 BUG 的提交里。

grep 命令是在查找 commit 提交标题里有 fix bug broken 字样的标题（所以，做好 commit 规范很重要）！

还记得上面的第一句吗？如果与第一句里面的文件有重合，那就是需要重视的风险代码。

第四句，看看每个月的提交次数

代码

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

运行后会输出这种样子：

12 2026-05 
35 2026-06 
18 2026-07

这个对于判断项目活跃度很重要。

有助于我们了解项目是在发展还是消亡。每月都提交次数稳定是最好的，如果某个月突然少了，那就是有成员离开了，如果按月来看，越来越少，那说明团队正在失去动力。

第五句，过去一年的回退操作

代码

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

不过，其实得多加一点，很多团队做不到那么规范：

git log --oneline --since="1 year ago" |
grep -iE 'revert|hotfix|fix|emergency|rollback|restore|recover|urgent|临时|紧急|回退|回滚|恢复|线上|修复'

这个命令是查找过去一年里的回退操作记录的。有助于去了解团队的应急处理频率。

一年回滚几次很正常，如果平均每隔几周就回滚一次，那说明团队内部有问题了。

如果压根儿就没有记录，有可能说明团队不规范，当然也有可能团队进行的很好。