读任何代码前，先跑这 5 个 Git 命令

原文来源：The Git Commands I Run Before Reading Any Code — 接手一个新代码库时，先用 5 个 Git 命令诊断项目健康状况，再打开任何一个文件。

我接手一个新代码库时，第一件事不是打开代码，而是打开终端跑几个 Git 命令。在你看任何文件之前，提交历史会给你一张项目诊断图：谁写的代码、问题集中在哪、团队是自信地交付还是在雷区里踮脚走。

1. 什么东西改得最多

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

从 app/ 或 src/ 目录跑，而不是项目根目录。否则锁定文件、变更日志和自动生成的代码会把列表结果带到天上去。

过去一年修改最多的 20 个文件。排在顶部的文件几乎一定是别人警告过你的那个——"那文件啊，没人敢碰。"

一个文件修改频率高不一定代表它写得差。有时只是它处于活跃开发中。但如果一个文件既高频修改又没人愿意认领，这就是我见过最明确的代码库拖累信号。那个文件每一次改动都是在补丁上叠补丁。一个小修改的波及面不可预测。团队估算工期时会故意拉长时间，因为他们知道这文件一定会跟你对着干。

2005 年微软研究院的一份研究发现，基于修改频率的指标比单纯基于复杂度的指标更能准确预测缺陷。我会把这列表前 5 个文件跟下面的 Bug 热点命令做交叉对比。一个既高频修改又高 Bug 量的文件，就是你最大的风险。Adam Tornhill 的 《Your Code as a Crime Scene》（第二版）构建了一套完整的基于修改频率的分析方法论，包括这些简单命令覆盖不到的复杂度叠加分析。

2. 谁写的代码

git shortlog -sn --no-merges

每位贡献者按提交次数排序。如果一个人占了 60% 或更多，这就是你的公交因数。如果这个人半年前已经走了，那这就是危机。如果全局 shortlog 里的头号贡献者没有出现在过去 6 个月的数据里（git shortlog -sn --no-merges --since="6 months ago"），我会立刻向客户指出。

我也会看列表尾部。30 个贡献者，但过去一年只有 3 个人活跃。当初搭建这个系统的人和现在维护它的人不是同一批。

需要注意：如果团队用了 squash-merge 工作流，提交历史会被压缩。这时 shortlog 的输出反映的是谁做了合并，不是谁写了代码。在得出结论之前，值得先问一下团队的合并策略。

3. Bug 集中在哪

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

和修改频率命令结构相同，只过滤包含 Bug 相关关键词的提交。把这个列表跟修改热点做对比。同时出现在两个列表上的文件就是你的最高风险代码：它们反复出问题、反复被打补丁，但从来没有被真正修好。

这个命令依赖提交信息的质量。如果团队每条提交都写"update stuff"，那什么都查不出来。但哪怕是一张粗糙的 Bug 密度地图，也比没有地图强。

4. 项目在加速还是走向死亡

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

按月份统计的提交量，覆盖项目整个历史。扫描输出，看曲线的形状。稳定的节奏是健康的。但如果某个月的提交量突然腰斩呢？通常意味着有人走了。一条持续 6 到 12 个月的下滑曲线告诉你团队在失去动力。周期性的峰值之后是安静期，说明团队把工作堆在发布窗口里分批交付，而不是持续发布。

我曾经给一个 CTO 看他们团队的提交速度图，他说"那正是我们流失第二位高级工程师的时间点。"在那之前，他从没把这两件事联系在一起。这是团队数据，不是代码数据。

5. 团队在救火的频率

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

回退和热修复的频率。一年内有几次是正常的。每隔几周就回退一次，说明团队不信任自己的部署流程。它们是更深层问题的证据：靠不住的测试、缺少预发布环境、或者部署管线的回滚操作过于复杂。零结果也是信号——要么团队极其稳定，要么没人写有意义的提交信息。

危机模式很容易判断。要么有，要么没有。

这 5 个命令花几分钟就能跑完。它们不会告诉你一切。但你会知道先读哪些代码，以及到了那里该看什么。这就是在第一天系统性地读代码和第一天盲目乱逛的区别。