在阅读任何代码之前我运行的 Git 命令

原文地址：https://piechowski.io/post/git-commands-before-reading-code/

以下为AI翻译内容：

在打开单个文件之前，这五个 Git 命令可以告诉你代码库的痛点在哪里。包括代码变更热点、核心人员依赖（Bus Factor）、Bug 聚集地以及危机模式。

当我接手一个新的代码库时，我通常做的第一件事并不是打开代码，而是打开终端并运行几个 Git 命令。在查看单个文件之前，提交历史（Commit History）能给我提供一份关于项目的诊断图谱：它是谁构建的、问题聚集在哪里、团队是自信地发布代码，还是在雷区边缘小心翼翼地行走。

1. 变更最频繁的地方（What Changes the Most）

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

这是过去一年中变更最频繁的 20 个文件。排在第一位的文件几乎总是人们会警告我不要碰的那个。“哦对，那个文件。每个人都害怕去修改它。”

高变更率（High churn）并不意味着代码质量差。有时仅仅是因为开发活跃。但当一个文件变更率很高，却没人愿意拥有它时，这是我所知道的代码库拖累最清晰的信号。那是每一个变更都是在补丁之上打补丁的地方。微小修改的波及范围（Blast Radius）是不可预测的。团队会因此拉长预估时间，因为他们知道代码会“反抗”。

引用： 2005 年微软研究院的一项研究发现，基于变更率的指标比单纯的复杂度指标更能可靠地预测缺陷。我会从这个列表中取出前 5 个文件，并与下面的 Bug 热点命令进行交叉比对。一个既高变更又高 Bug 的文件是你最大的单一风险。

2. 谁构建了这个系统（Who Built This）

git shortlog -sn --no-merges

按提交次数排名的每一位贡献者。如果一个人贡献了 60% 或更多的代码，那就是你的核心人员依赖（Bus Factor）。如果这个人六个月前离职了，那就是一场危机。如果在整体排名中贡献最多的作者在最近 6 个月的窗口期（git shortlog -sn --no-merges --since="6 months ago"）中没有出现，我会立即向客户发出警告。

我也会关注长尾部分。如果有三十位贡献者，但过去一年只有三位活跃。构建这个系统的人并不是维护它的人。

注意： Squash-Merge（压缩合并）工作流会压缩作者信息。如果团队将每个 PR 压缩成一个单一的提交，这个输出反映的是谁合并了代码，而不是谁写的。在得出结论之前，值得先询问一下他们的合并策略。

3. Bug 聚集在哪里（Where Do Bugs Cluster）

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

与变更命令形状相同，但过滤了包含 bug 相关关键词的提交。将此列表与变更热点进行对比。同时出现在这两个列表中的文件是风险最高的代码：它们不断崩溃，不断被打补丁，但从未被真正修复。

这取决于提交信息的规范程度。如果团队每次提交都写“更新东西（update stuff）”，那你将一无所获。但即使是一个粗糙的 Bug 密度地图也比没有地图要好。

4. 这个项目是在加速还是在消亡（Is This Project Accelerating or Dying）

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

整个仓库历史中按月统计的提交数量。我扫描输出结果以寻找“形状”。稳定的节奏是健康的。但如果数量在一个月内下降了一半，那意味着什么？通常是有关键人员离开了。6 到 12 个月的下降趋势告诉你团队正在失去动力。周期性的峰值后跟随着安静的月份，意味着团队将工作批量打包成版本发布，而不是持续交付。

我曾给一位 CTO 展示过他们的提交速度图表，他们说：“那是我们失去第二位高级工程师的时候。”他们之前从未将时间线联系起来。这是团队数据，而非代码数据。

5. 团队多久进行一次“救火”（How Often Is the Team Firefighting）

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

回滚（Revert）和热修复（Hotfix）的频率。一年内有几次是正常的。每两周几次回滚意味着团队不信任他们的部署流程。这是更深层问题的证据：不可靠的测试、缺少预发环境，或者部署流水线让回滚变得比应有的更困难。零结果也是一种信号；要么团队很稳定，要么没人写描述性的提交信息。

危机模式很容易阅读。要么存在，要么不存在。

这五个命令只需要几分钟就能运行。它们不会告诉你一切，但你会知道首先该阅读哪些代码，以及到达那里时该寻找什么。