所有提交中有15%是修复吗？（2025）

# 15%的提交都是修复吗？ 来源：https://carvalho.sh/posts/2025-07-29-are-15-of-all-commits-fixes **简言之**：更接近10%。 我最近开始了一份新工作，拿到代码库访问权限后最先做的几件事之一，就是查看它的各种统计数据。 比如：代码库存在多久了、总共有多少提交、谁是主要贡献者、哪些文件被修改过最多次、是使用合并提交还是线性历史记录等等。 其中，"修复"类型提交的占比尤其让我感兴趣。也就是说，所有提交中有多少是修复性质的。为简单起见，从现在起我将其称为"修复占比"。 在我接触过的多个代码库以及不同公司的环境中，大多数生产级软件的修复占比似乎都在15%左右浮动。 而当我对主代码库运行命令时： ``` λ numbat -e $(git log --oneline | grep -iw fix | wc -l)/$(git rev-list --count --all) 0.148675 ``` 看，又是经典的15%。 这让我产生了疑问：**其他公开代码库的修复占比是否也接近这个范围？** 于是我开始寻找GitHub上一些具有一定影响力的代码库列表，同时清楚以下几点： - a) 开源软件和闭源软件（我观察到15%比例的）是两类不同的产品； - b) 并非所有热门仓库都是应用程序，很多只是文本集合的"精选列表"； - c) 即使能快速获取一定数量的仓库，样本依然可能不具备代表性。 我从这里（https://gitstar-ranking.com/repositories）获取了前200个仓库的列表。 尽管存在这些局限性，我还是下载了114GB的数据（附注1），准备计算最终答案。 ## 准备工作 首先，我将每个仓库的"修复"提交数和总提交数提取到`output.csv`文件中。 请注意，以下脚本依赖GNU Parallel（https://www.gnu.org/software/parallel/）。 ```bash # 文件: count.sh #!/usr/bin/env bash set -euo pipefail function count_repo { repo=$1 num_fixes=$(git -C $repo log --oneline | grep -iw fix | wc -l) num_commits=$(git -C $repo rev-list --count --all) echo $repo,$num_fixes,$num_commits } # 导出函数以便在下面的'parallel'命令中使用 export -f count_repo function main { # 写入CSV表头 echo 'repo,num_fixes,num_commits' # 遍历每个仓库，统计修复提交数和总提交数 find -maxdepth 1 -type d -execdir test -d {}/.git \; -print -prune | parallel --jobs 8 count_repo } main | tee output.csv ``` ``` λ ./count.sh repo,num_fixes,num_commits [...] ./opencv,4338,36425 ./next.js,5405,38047 ./rust,28281,306211 ./rails,11212,113647 ./vscode,23092,145918 ./tensorflow,18848,191525 ./linux,198048,1369404 ``` 接着，我计算了修复占比，并使用DuckDB分析结果。`SUMMARIZE`命令（https://duckdb.org/docs/stable/guides/meta/summarize.html）对这类快速分析非常有用。 ```sql -- 文件: analyze.sql .mode line summarize select num_fixes/num_commits as fix_ratio from 'output.csv'; ``` ``` λ duckdb < analyze.sql column_name = fix_ratio column_type = DOUBLE min = 0.0 max = 0.35591287490021667 approx_unique = 172 avg = 0.10526396442532608 std = 0.07332227658614995 q25 = 0.05261715331694921 q50 = 0.09326059309410577 q75 = 0.14624197878941886 count = 200 null_percentage = 0.00 ``` ## 结果分析 由于没有对数据进行任何清洗，结果存在一定波动是意料之中的。但从这200个开源仓库的样本来看，修复提交的占比似乎更接近10%，而非15%。 ## 这意味着什么？ 虽然不如之前看到~15%比例时那样有共鸣，但我认为这仍然是一个合理的估算。如果你的修复占比在10%-20%之间，我想你大概能睡得安稳，不用经常凌晨三点起来修复生产环境问题。如果你维护的项目简直是个烂摊子，我很好奇——你的修复占比是多少？ 总的来说，你需要注意这个比例吗？可能不必。 ## 注意事项 - 你需要某种程度上遵循语义化提交规范，或者至少在提交信息中包含`fix`字样。 - 频繁使用合并的代码库可能不符合这个比例。 ## 关键启示 1. 使用GNU Parallel：这是一个非常便捷的工具（https://carvalho.sh/posts/2025-06-01-gnu-parallel-as-a-poor-mans-scraper/）。 2. 使用DuckDB，特别是`SUMMARIZE`命令，可以快速进行统计分析。 3. 接受一个事实：大约10%的变更可能需要修复。 --- 1. 公平地说，其中32.2GB仅来自nerd-fonts（https://github.com/ryanoasis/nerd-fonts）项目。↩（https://carvalho.sh/posts/2025-07-29-are-15-of-all-commits-fixes#fr-1-1）