Git

接手一个陌生代码库时，大多数人的第一反应是打开源码目录开始翻文件。Ally Piechowski 在 The Git Commands I Run Before Reading Any Code 里给出了另一条路：先别读代码，先读 git 历史。提交记录里藏着代码质量、团队健康度和项目风险的大量信号， 五条命令就能把它们挖出来。本文是这篇文章的摘要笔记。 1. 变更热点：哪些文件被改得最多 git log --format=format: --name-only --since="1 year ago" \ | sort | uniq -c | sort -nr | head -20 列出过去一年改动次数最多的 20 个文件。高频变更本身不一定是坏事，但高变更 + 低所有权的文件 是典型的风险区：改动零碎、难以预测，还会悄悄拖垮团队的排期估算。作者引用了微软研究院 2005 年的 一项研究：按组件规模归一化后的「相对 churn」，比绝对改动次数更能预测缺陷密度。 2. Bus Factor：项目压在几个人身上 git shortlog -sn --no-merges 按提交量给贡献者排序。如果一个人占了 60% 以上的提交，这就是一个关键依赖风险——尤其当这个人 已经半年没出现在提交记录里。作者建议顺手确认一下：历史上的头部贡献者，最近是否还活跃。 注意：squash merge 工作流会掩盖真实作者——统计反映的是「谁合并的」，不是「谁写的」。 3. Bug 聚集：哪些文件反复出问题 git log -i -E --grep="fix|bug|broken" --name-only --format='' \ | sort | uniq -c | sort -nr | head -20 找出提交信息里带 fix / bug / broken 的文件。把这份榜单和第 1 条的 churn 榜单对照着看， 交集就是风险最高的代码：反复出 bug、却从未被认真重构的文件。 ...