今天想聊聊 git 代码量统计。原因很简单马上又到了季度总结和年度复盘的时候组里好几个同学都在问同一个问题——“怎么把我今年写的代码量统计出来”每次遇到这种需求我都发现大家其实并不缺少工具而是被“统计口径”绕晕了同一个仓库别人跑出来的数字可以比你多一倍不是工具坏了而是命令参数、过滤条件、合并提交处理方式不同。这篇东西我打算从统计的真实用途、工具选型、核心原理、实操命令到避坑指南一次讲完适合三类人看要写季度汇报和简历的普通开发者、需要摸清团队产出的技术管理者、以及单纯想看看自己一年到底写了多少行代码的独立开发者。放心看完你不仅能跑出一份数字还能解释清楚这份数字是怎么来的。1. 为什么需要统计git代码量被低估的真实需求1.1 统计不只是为了汇报大部分人是被“绩效季”逼着来查代码量的。这种需求最朴素也最容易踩坑因为直接执行git log --shortstat拿到的是全仓库所有分支、所有作者的累计变化量跟“你个人这个季度写了多少”完全是两回事。但我更想说的是代码量统计还有几个被低估的使用场景。第一是简历和项目复盘。写简历时“负责xx模块开发”这种描述太虚如果能在项目经历里补一句“三个月内完成xx模块核心功能累计提交 120 次代码净增约 8000 行”说服力会强很多。当然这种数据的前提是你自己会统计并且清楚其中的水分在哪里——比如是否包含自动生成代码、是否引入了第三方依赖。第二是估算重构范围。我曾经需要评估一个老模块的重构工作量第一反应不是看文档而是直接跑了这个模块的代码变动统计在最近一年里哪些文件被修改次数最多、累计变更行数最大哪个文件几乎没人动过。结果非常直观被改了三十多次的配置文件、频繁变动的实体类基本就是业务最不稳定、重构风险最高的地方。这种分析比凭感觉拍脑袋靠谱得多。第三是团队协作的健康度观察。当一个仓库的代码量统计出现“单日提交 50 次、单文件一次修改 2000 行”这类异常值时往往意味着有人在暴力合并、在赶工补功能或者分支策略出了问题。统计数字本身没有善恶但它可以作为代码评审之外的辅助信号。1.2 统计在项目健康度分析中的价值很多人反感“用代码量衡量贡献”这个观点我部分认同。代码行的多寡确实不能代表代码质量一个 200 行的聪明抽象可能顶得上别人 2000 行冗余实现。但反过来如果完全拒绝量化团队会陷入另一个极端——什么都靠感觉。我的实践是把代码量统计当作“温度计”而不是“评分卡”。温度计告诉你发烧了但不会告诉你病因。同理统计数据暴露出的信号有某个文件长期被高频修改说明模块边界设计可能有问题某个作者短期提交暴增说明可能存在集中式“填坑”某个目录变更行数极少但提交次数很多说明大家都在做微调缺乏结构性改进新增行数和删除行数几乎相同说明这段时期大概率在做重构或需求反复。这些判断不需要特别复杂的工具只要把某个时间段内、某个路径下的增删行数拉出来再配合git log --oneline看一下提交信息就能自己得出结论。所以在开始敲命令之前我建议你先想清楚一个问题这份数据你打算用来做什么是写给领导看的、写简历用的、还是自我诊断项目健康的这个问题决定了后面的统计口径和工具选择。下面几节我会沿着不同的使用场景给出对应的方案。2. 统计工具选型从原生命令到可视化报告2.1 git log 家族最灵活但需要懂点 awk说到代码量统计绕不开 git 自带的git log命令。它最大优势是完全离线、无需安装额外工具只要你本地仓库完整随时能跑。它的统计能力体现在几个核心参数上--shortstat在每次提交的摘要后输出变更文件数和增删行数--numstat按文件输出新增行数和删除行数精确到每个文件--stat按文件列出变更行数的详细视图带比例条--author/--committer按作者或提交者过滤--since/--until按时间范围过滤--no-merges排除合并提交-- path限定只统计某些路径。最基础的组合命令长这样git log --author你的名字或邮箱 --since2024-01-01 --until2025-01-01 --oneline --shortstat跑出来的结果是一串提交记录和对应的“N files changed, M insertions(), K deletions(-)”它没用直接汇总。真正的汇总需要把输出交给 awk 或脚本处理。很多人在这一步卡住了实际上只要写一个小管道就能解决具体见后面第 4 节。git log家族适合快速查询和临时统计你随时改一个参数就能换一个维度比如只看某个路径、只看某个分支。它不适合直接输出漂亮的报表也不适合统计“当前代码库总共多少行代码”——那是另一种统计需要用 cloc 这类工具。2.2 专用统计工具与IDE插件除了原生命令还有几类工具能帮你省事。git shortlog是最接近“开箱即用”的原生命令git shortlog -sne --since2024-01-01能以作者分组统计每个人的提交次数和提交邮箱。注意它统计的是“提交次数”而不是“代码行数”适合看活跃度不适合看代码量。cloc是另一个很有用的独立工具它统计的是“代码仓库当前有多少行代码”然后按照编程语言分类输出。这个数字和git log的变更行数完全不是一个概念一个是存量一个是流量。两者对应的是不同问题——“这个项目多大”和“这个阶段写了多少”。GitStats是一个生成 HTML 报告的 Python 工具能在拉取 git 历史后生成包括提交时间分布、作者排名、文件热度、每日代码量等丰富的图表。适合要做正式汇报、需要可视化展示的场景。缺点是生成速度受仓库历史长度影响历史很长的老仓库跑起来有点慢。IDE 插件方面JetBrains 系列里 Git Integration 自带的代码指标以及 VS Code 的 GitLens都能在文件层面看到作者的提交信息但这类工具更偏向“查看局部修改”不太适合做一整年的汇总统计。日常查几个文件的归属很好用指望它出一份年度统计报告就免了。2.3 工具对比到底该用哪个我把常用方案放在一个表里方便你对号入座。工具/命令统计口径输出形式适用场景git log --shortstat提交级别的增删行数文本需自己聚合单仓库快速统计个人代码量git log --numstat文件级别的增删行数文本可精确定位热点分析模块变更量、定位高频修改文件git shortlog -sne提交次数文本排行团队活跃度、提交量排名cloc当前代码物理行数文本/表格项目规模评估、技术栈盘点GitStats历史综合指标HTML 报告季度/年度总结、可视化展示GitLens 等插件文件层面的行级归属IDE 内面板日常浏览代码时查看归属不适合汇总个人建议日常自己查数据用 git log 一个小脚本就够了要给别人看、要截图汇报用 GitStats要评估现有仓库规模用 cloc。尽量别在插件里面找“年度汇总”按钮你把精力花在读懂 git log 的输出上收获会大得多。3. 统计口径为什么同一个仓库能跑出三种结果3.1 commit 粒度与 diff 行数先认识 git 统计的基本单位。git log --shortstat里输出的“5 insertions() 3 deletions(-)”表示的是某次提交相对于它父提交产生的新增和删除行数。这个数字基于 diff 算法按行比较不按字符比较。所以一个关键结论git 统计的是“变更”不是“当前有多少行”。哪怕你只是把一行代码从文件底部挪到顶部diff 也可能算出 1 insertion 和 1 deletion。如果一次提交里把整个文件的行尾从 LF 换成 CRLF统计结果会爆炸式增长因为每一行都被判定为新增和删除。另一个很多人忽略的问题同一行代码被改动一次统计里就记一次新增加一次删除。假设同一行在今年被三个人各修改了一次它会计入三对增删。这没问题因为“变更量”本质就是这样定义的。但是如果你想统计“最终代码库的规模”这个指标完全无效——这就是为什么不要让 git log 和 cloc 混为一谈。3.2 合并提交、cherry-pick 与重复计算代码量统计最大的水分来源是合并提交和跨分支复制。默认情况下git log --shortstat并不会为合并提交输出 diff 统计因为它有一个父提交以上git 默认不展示合并提交的 diff。但如果你用了-m参数git 会把合并提交和每一个父提交分别比一遍那就会产生多份 diff统计结果瞬间膨胀。所以普通统计请在命令里加上--no-merges只统计普通提交。还有 cherry-pick 问题。如果一个 commit 从 feature 分支 cherry-pick 到 release 分支它在这两个分支上各出现一次。你在 release 分支上统计时会把这个 commit 完整算一遍在 feature 分支上再统计一遍又会算一次。如果你只是想统计“这段代码是谁写的”这没什么问题如果你想统计“今年产生了多少行新代码”重复提交会让数据虚高。分支合并带来的另一个问题是如果你在master分支上跑统计而团队的开发流程是“develop 分支合回 master”那么所有经过 merge 进入 master 的功能代码都不会被--no-merges的常规统计捕获。这种情况下正确的做法是在实际开发分支上统计或者使用git log --first-parent来追踪主干合入记录。这个问题几乎每个团队都会踩我认为是整个代码量统计中最需要提前想清楚的坑之一。3.3 作者与提交者、时间与时区git 里一个提交有两类身份Author 是代码的原始作者Committer 是把这个提交实际写进仓库的人。自己提交自己的代码时二者相同在git rebase、git commit --amend、或者由 CI 机器人代为提交时二者就会分离。--author过滤的是 Author--committer过滤的是 Committer。如果你想统计“谁写了这段代码”用--author如果你想统计“谁把代码合进来的”用--committer。举一个真实例子组里有个自动化工具会把所有人的改动整合后统一提交Committer 都是机器人账号。如果用 Committer 统计你会发现自己提交次数为 0用 Author 统计才正常。时间和时区也需要留意。--since和--until默认按本地时区解析但提交记录的时区存的是作者提交时的本地时区。如果你的时间过滤字符串是--since2024-01-01而某次提交的 Author 时区是 UTC8git 在比较时会做时区换算。简单结论跨年统计不要纠结边界上的那一两笔提交时区造成的偏差通常可以忽略但在精确到“某天”的统计里记得留意仓库里的提交时区设置。4. 实操方案单仓库与多仓库的代码量统计4.1 一条命令搞定个人季度代码量先用最日常的需求开头统计我自己在某个时间段写入了多少行代码。我通常用这组命令git log --author你的名字 --since2024-01-01 --until2024-03-31 --no-merges --oneline --shortstat输出结果包含了每一笔提交的次数和行数变化但需要汇总。我写了一个比较通用的 awk 聚合命令git log --author你的名字 --since2024-01-01 --until2024-03-31 --no-merges --oneline --shortstat | awk /^[0-9a-f]{7,}/ { commits } /files? changed/ { split($0, a, ,) for (i in a) { if (a[i] ~ /insertion/) { gsub(/[^0-9]/, , a[i]); insert a[i] } if (a[i] ~ /deletion/) { gsub(/[^0-9]/, , a[i]); delete a[i] } } } END { printf commits: %d, insertions: %d, deletions: %d, net: %d\n, commits, insert, delete, insert - delete }解释一下这个脚本的逻辑git log 输出的每一笔提交是一行 hash 提交信息紧接着一行 shortstat 摘要。awk 遇到以至少 7 位十六进制字符开头的行就把 commit 计数加一遇到包含 “files changed” 的行就把它按逗号切分成几段从中提取 insertions 和 deletions 的数字。最后输出提交次数、总新增、总删除和净增。我在实际使用中发现这个脚本可以满足 80% 的个人统计场景。如果提交信息很长、hash 缩写位数变化正则[0-9a-f]{7,}都能兼容。唯一要注意的是如果你的提交信息碰巧由数字开头并且恰好有 7 位以上这个脚本可能误判。解决办法是改用--prettyformat:%h明确提交行格式但日常使用中出现这种误判的概率很低。4.2 按文件维度统计热点代码有时候你不能只看总量还得知道“哪些文件被改得最狠”。这时候用--numstat更合适。它输出的每一行是“新增行数、删除行数、文件路径”非常适合按文件聚合。基础命令git log --no-merges --numstat --prettyformat: --since2024-01-01 --until2024-12-31 --author你的名字注意--prettyformat:会把提交信息这一行去掉只保留 numstat 数据。然后用 awk 汇总每个文件的累计变更git log --no-merges --numstat --prettyformat: --since2024-01-01 --until2024-12-31 --author你的名字 | awk $1 ~ /^[0-9]$/ $2 ~ /^[0-9]$/ { added[$3] $1 deleted[$3] $2 } END { for (f in added) { total[f] added[f] deleted[f] } for (f in total) { print total[f], added[f], deleted[f], f } } | sort -rn | head -20这里 awk 判断前两个字段是否都是纯数字避免把二进制文件行显示为“-”和异常输出混进来。最后按总变更行数排序取前 20 个文件能很快发现热点模块。在我自己的项目里这个命令最有价值的发现是有些文件虽然提交次数不多但单次改动超过 1000 行这种“一次性大变更”往往是合并、格式化或大重构造成的会让评审难度暴增。看到这类数据后我会建议团队拆小提交把纯格式变更和业务逻辑变更分开。4.3 多仓库下的一键统计脚本很多人的开发工作横跨多个仓库比如一个后端服务、一个前端工程、一个公共组件库。逐个进入目录执行命令太麻烦我写了一个简单的 bash 脚本跑完所有子目录下的 git 仓库汇总各仓库的提交数和增删行数#!/bin/bash author${1:-你的名字} since${2:-2024-01-01} until${3:-2025-01-01} for dir in */; do if [ -d $dir/.git ]; then cd $dir result$(git log --author$author --since$since --until$until --no-merges --oneline --shortstat | awk /^[0-9a-f]{7,}/ { commits } /files? changed/ { split($0, a, ,) for (i in a) { if (a[i] ~ /insertion/) { gsub(/[^0-9]/, , a[i]); ins a[i] } if (a[i] ~ /deletion/) { gsub(/[^0-9]/, , a[i]); del a[i] } } } END { printf %d/%d/%d, commits, ins, del }) echo $dir: $result cd .. fi done把脚本保存为git-stats.sh执行bash git-stats.sh 你的邮箱 2024-01-01 2024-12-31即可。脚本里的${1}和${2}允许你传参不传就用默认值。输出格式是“仓库名: 提交数/新增行数/删除行数”一眼能看清每个仓库的贡献量。这个脚本我在多个团队里用过稳定性还不错。唯一的提醒是不要在仓库目录里直接运行另一个仓库的脚本时搞混当前目录脚本每次cd $dir后必须cd ..退回否则第二次循环会跑到错误目录。我一开始写脚本时漏了这个导致结果全是同一个仓库的重复数据。4.4 生成可视化报告与物理行数统计如果你要给领导做汇报纯文本输出可能不够直观建议用 GitStats 生成 HTML 报告。# 安装 pip install gitstats # 生成报告gitstats 仓库路径 输出目录 gitstats ./ /tmp/my-report生成的index.html里包含作者提交排行、每日活动、文件热图等图表是季度汇报的好素材。但还是那句老话它是基于整个仓库历史生成的不是按你的个人过滤。如果你只想展示某个人的数据建议先单独克隆一份仓库或者直接看第 4.1 节里的文本统计。如果想统计“当前代码库到底有多少行代码”用 cloccloc . --exclude-dirnode_modules,vendor,dist --include-langPython,JavaScript注意 cloc 统计的是当前工作区里所有文件的行数和 git 历史无关。它能按语言分类输出适合回答“改造前这个项目有多少行 Python、多少行 JavaScript”。配合 git 的变更统计就能从“存量”和“流量”两个维度完整描述一个项目。5. 统计前置条件提交规范和环境对结果的影响5.1 提交信息规范与统计过滤统计代码量听着像是技术活其实结果很大程度取决于团队的提交规范。提交信息写得不规范过滤就会变得很痛苦。比如你想区分“功能性提交”和“修 bug 的提交”如果团队里有人写fix: 修复登录超时有人写改了一下还有人一个巨型提交塞了三个功能你的统计就只能停留在“总代码量”层面无法往下拆分。如果团队已经使用 Conventional Commits 之类的规范你可以用--grep按提交信息过滤# 统计以 feat 开头的提交 git log --author你的名字 --since2024-01-01 --until2024-12-31 --grep^feat --oneline # 统计包含 fix 的提交及其代码量 git log --author你的名字 --since2024-01-01 --until2024-12-31 --no-merges --grep^fix --shortstat | awk ...没有规范也没关系统计前先花十分钟git log --oneline快速扫一眼提交信息的风格就知道哪些关键字可以用于过滤。我自己见过不少仓库 70% 的提交信息都是update、test、merge这种仓库里的“按功能类型统计”基本没法做。想改善这一点只能靠提交规范推广。还有一个容易忽略的点git commit --amend会修改提交信息、改动提交哈希和时间线。如果团队里有人频繁 amend 已经推送的分支你在--since时间过滤时会看到提交时间往后“漂移”了导致某段时间的统计数字奇低。这不是统计工具的问题是提交历史已经被重写过了。所以如果你的统计周期是精确到“某一天”的最好先确认这段时间内有没有人重写过历史。5.2 分支合并和子模块带来的统计陷阱分支模型对统计结果的影响我在第 3.2 节提过一部分。这里补充一个常见的具体场景有人直接在master上统计结果发现自己的代码量为 0原因是他所有的提交都先在dev分支上完成最后通过 merge 操作合入master而--no-merges把合并提交排除掉了。正确的做法之一是在你的日常开发分支上统计而不是在合并目标分支上统计。如果你已经形成了固定的分支命名习惯比如feature/*可以在命令里加路径过滤或分支过滤git log --author你的名字 --no-merges --since2024-01-01 --until2024-12-31 --shortstat feature/my-module子模块也值得单独说。主仓库里引用了 submodulegit log在主仓库内只能看到 submodule 指针的变化看不到子模块内部的代码提交。要统计子模块的代码量必须进入子模块目录单独跑统计。我第一次统计一个含子模块的项目时漏掉了所有子模块的数据最后总量少了差不多三分之一。5.3 快捷环境检查认证、过滤文件与目录安全在开始统计之前建议顺手做几个环境检查避免跑一半才发现仓库状态不对。第一是认证问题。统计本地历史其实不需要认证但如果你需要先git fetch拉取最新分支或者用脚本从远端克隆仓库就可能遇到 SSH 认证失败。遇到的时候先验证一下ssh -T git你的代码托管平台地址确认公钥配置正常也可以用 HTTPS 协议加 token 代替 SSH。这个排查顺序基本能解决 90% 的认证问题。第二是过滤文件。很多人以为.gitignore能影响 git 统计实际上它只作用于“尚未被跟踪的文件”。如果某天你把dist或node_modules提交进了仓库之后就算在.gitignore里加上它们也没用因为它们已经被 git 跟踪了。要恢复得靠git rm -r --cached dist把文件从索引里移除。这个坑在统计时尤其致命如果你统计的仓库里 isset 早前误提交了大量依赖目录任何代码量统计都会被这些第三方文件淹没。第三是目录安全。近两年经常能看到“git 目录泄露”相关的话题本质是网站把.git/目录暴露在公网导致源码被下载。作为开发者比起研究怎么下载别人暴露的仓库更应该先检查自己的服务器是否拒绝外部访问/.git/路径避免代码被爬走。统计代码量和这个没有直接关系但仓库一旦泄露后续的风险远大于统计数字本身。6. 常见问题与排查技巧实录6.1 问题速查表我在帮同事调试统计命令时攒了不少典型问题先整理成表格现象可能原因解决办法统计结果比别人少很多统计口径不同比如排除了合并提交、过滤了某些作者、时间范围不同统一明确参数对比时先确认双方使用的命令一致统计结果虚高仓库里包含 dist、node_modules、vendor 等目录用-- path过滤路径或先git rm -r --cached掉误跟踪的目录用 --author 查不到某个人的提交提交人改了邮箱或者提交作者名和显示名不一致用git log --format%an %ae查看完整作者信息提交信息中文乱码终端编码问题和 git 的路径转义执行git config --global core.quotepath false把终端设为 UTF-8Windows 下命令行跑 awk 报错PowerShell 管道和 awk 兼容性差使用 Git Bash 执行不要在 PowerShell 里直接跑复杂管道统计时偶尔出现 “git open /dev/null or dup failed” 相关报错系统默认 shell 或终端工具链异常检查 SHELL 环境变量尽量在 Git Bash 或标准终端里操作只读命令总仓库跑 GitStats 非常慢仓库历史太长提交次数过多先用小仓库或--since过滤测试生成报告时可排除某些目录6.2 踩坑记录与个人心得多讲几个我在实际统计过程中印象比较深的细节。关于“作者名查不到”的问题。git 的 Author 并不总是等于你在托管平台上的用户名。有人本机配置的是user.name昵称邮箱是临时邮箱后台统计系统按邮箱归一你按名字一查发现统计结果为零。碰到这种情况建议先跑一句git log --format%h %an %ae --since2024-01-01把仓库里真实出现的作者名和邮箱列出来再去写过滤条件。关于“大文件提交失败”和统计的关系。很多团队会遇到git 无法提交大文件的问题比如资源文件超过托管平台限制。处理这类问题通常建议接入 LFS而不是把大文件塞进普通 git 仓库。从统计角度看大文件一旦被提交进仓库虽然不会直接增加代码行数但会让git log遍历历史变慢还会让 clone 体积膨胀。所以遇到仓库越来越慢的时候第一件事不是优化统计命令而是查一下历史里有没有混入大文件。关于“提交次数”和“代码行数”的错位。git shortlog -sne显示的提交次数高不代表代码量就大。有的人习惯小步提交一天提交 20 次有的人一个大功能写完才提交 1 次。这两种人的 shortlog 排名差异很大但代码量可能差不多。所以做团队对比时我通常会同时看提交数和变更行数不能只用一个指标下结论。还有一个让我印象很深的教训在一个历史较长的仓库里直接用git log --author... --since...统计时没有加--no-merges结果多统计出接近一倍的代码量。排查后才发现那个仓库的合并策略会把所有功能分支的变更在 merge 提交里再算一遍等于把原有代码量重复计了一次。所以“统计前先想清楚要不要排除 merge 提交”这句话我几乎每次都会对同事重复一遍。最后如果你发现一个仓库的代码量统计结果和预期差异极大不要急着怀疑工具。先跑一下不带任何过滤条件的git log --oneline | wc -l看看总提交数再逐步加过滤条件对比数字变化。这种“逐步缩小范围”的排查方式比直接看最终统计结果有效得多。我个人在实际工作里已经习惯把统计命令做成一个简单的 shell 脚本每次需要时传入作者和时间范围几秒钟出结果。用多了之后最大的感受是代码量数据最动人的地方不在于它证明你写了多少行而在于它能帮你回顾某一段时间的修改节奏。比如我去年年末复盘时看到某个模块在两周里被连续修改了二十多次才发现当初的抽象设计没做好。这个信号远比“我写了八万行代码”这句总结有实际价值。 
长河君 · 2026/10/8 21:39:02 · 阅读 1.2k Git代码量统计完全指南：从命令、工具到统计口径避坑
今天想聊聊 git 代码量统计。原因很简单马上又到了季度总结和年度复盘的时候组里好几个同学都在问同一个问题——“怎么把我今年写的代码量统计出来”每次遇到这种需求我都发现大家其实并不缺少工具而是被“统计口径”绕晕了同一个仓库别人跑出来的数字可以比你多一倍不是工具坏了而是命令参数、过滤条件、合并提交处理方式不同。这篇东西我打算从统计的真实用途、工具选型、核心原理、实操命令到避坑指南一次讲完适合三类人看要写季度汇报和简历的普通开发者、需要摸清团队产出的技术管理者、以及单纯想看看自己一年到底写了多少行代码的独立开发者。放心看完你不仅能跑出一份数字还能解释清楚这份数字是怎么来的。1. 为什么需要统计git代码量被低估的真实需求1.1 统计不只是为了汇报大部分人是被“绩效季”逼着来查代码量的。这种需求最朴素也最容易踩坑因为直接执行git log --shortstat拿到的是全仓库所有分支、所有作者的累计变化量跟“你个人这个季度写了多少”完全是两回事。但我更想说的是代码量统计还有几个被低估的使用场景。第一是简历和项目复盘。写简历时“负责xx模块开发”这种描述太虚如果能在项目经历里补一句“三个月内完成xx模块核心功能累计提交 120 次代码净增约 8000 行”说服力会强很多。当然这种数据的前提是你自己会统计并且清楚其中的水分在哪里——比如是否包含自动生成代码、是否引入了第三方依赖。第二是估算重构范围。我曾经需要评估一个老模块的重构工作量第一反应不是看文档而是直接跑了这个模块的代码变动统计在最近一年里哪些文件被修改次数最多、累计变更行数最大哪个文件几乎没人动过。结果非常直观被改了三十多次的配置文件、频繁变动的实体类基本就是业务最不稳定、重构风险最高的地方。这种分析比凭感觉拍脑袋靠谱得多。第三是团队协作的健康度观察。当一个仓库的代码量统计出现“单日提交 50 次、单文件一次修改 2000 行”这类异常值时往往意味着有人在暴力合并、在赶工补功能或者分支策略出了问题。统计数字本身没有善恶但它可以作为代码评审之外的辅助信号。1.2 统计在项目健康度分析中的价值很多人反感“用代码量衡量贡献”这个观点我部分认同。代码行的多寡确实不能代表代码质量一个 200 行的聪明抽象可能顶得上别人 2000 行冗余实现。但反过来如果完全拒绝量化团队会陷入另一个极端——什么都靠感觉。我的实践是把代码量统计当作“温度计”而不是“评分卡”。温度计告诉你发烧了但不会告诉你病因。同理统计数据暴露出的信号有某个文件长期被高频修改说明模块边界设计可能有问题某个作者短期提交暴增说明可能存在集中式“填坑”某个目录变更行数极少但提交次数很多说明大家都在做微调缺乏结构性改进新增行数和删除行数几乎相同说明这段时期大概率在做重构或需求反复。这些判断不需要特别复杂的工具只要把某个时间段内、某个路径下的增删行数拉出来再配合git log --oneline看一下提交信息就能自己得出结论。所以在开始敲命令之前我建议你先想清楚一个问题这份数据你打算用来做什么是写给领导看的、写简历用的、还是自我诊断项目健康的这个问题决定了后面的统计口径和工具选择。下面几节我会沿着不同的使用场景给出对应的方案。2. 统计工具选型从原生命令到可视化报告2.1 git log 家族最灵活但需要懂点 awk说到代码量统计绕不开 git 自带的git log命令。它最大优势是完全离线、无需安装额外工具只要你本地仓库完整随时能跑。它的统计能力体现在几个核心参数上--shortstat在每次提交的摘要后输出变更文件数和增删行数--numstat按文件输出新增行数和删除行数精确到每个文件--stat按文件列出变更行数的详细视图带比例条--author/--committer按作者或提交者过滤--since/--until按时间范围过滤--no-merges排除合并提交-- path限定只统计某些路径。最基础的组合命令长这样git log --author你的名字或邮箱 --since2024-01-01 --until2025-01-01 --oneline --shortstat跑出来的结果是一串提交记录和对应的“N files changed, M insertions(), K deletions(-)”它没用直接汇总。真正的汇总需要把输出交给 awk 或脚本处理。很多人在这一步卡住了实际上只要写一个小管道就能解决具体见后面第 4 节。git log家族适合快速查询和临时统计你随时改一个参数就能换一个维度比如只看某个路径、只看某个分支。它不适合直接输出漂亮的报表也不适合统计“当前代码库总共多少行代码”——那是另一种统计需要用 cloc 这类工具。2.2 专用统计工具与IDE插件除了原生命令还有几类工具能帮你省事。git shortlog是最接近“开箱即用”的原生命令git shortlog -sne --since2024-01-01能以作者分组统计每个人的提交次数和提交邮箱。注意它统计的是“提交次数”而不是“代码行数”适合看活跃度不适合看代码量。cloc是另一个很有用的独立工具它统计的是“代码仓库当前有多少行代码”然后按照编程语言分类输出。这个数字和git log的变更行数完全不是一个概念一个是存量一个是流量。两者对应的是不同问题——“这个项目多大”和“这个阶段写了多少”。GitStats是一个生成 HTML 报告的 Python 工具能在拉取 git 历史后生成包括提交时间分布、作者排名、文件热度、每日代码量等丰富的图表。适合要做正式汇报、需要可视化展示的场景。缺点是生成速度受仓库历史长度影响历史很长的老仓库跑起来有点慢。IDE 插件方面JetBrains 系列里 Git Integration 自带的代码指标以及 VS Code 的 GitLens都能在文件层面看到作者的提交信息但这类工具更偏向“查看局部修改”不太适合做一整年的汇总统计。日常查几个文件的归属很好用指望它出一份年度统计报告就免了。2.3 工具对比到底该用哪个我把常用方案放在一个表里方便你对号入座。工具/命令统计口径输出形式适用场景git log --shortstat提交级别的增删行数文本需自己聚合单仓库快速统计个人代码量git log --numstat文件级别的增删行数文本可精确定位热点分析模块变更量、定位高频修改文件git shortlog -sne提交次数文本排行团队活跃度、提交量排名cloc当前代码物理行数文本/表格项目规模评估、技术栈盘点GitStats历史综合指标HTML 报告季度/年度总结、可视化展示GitLens 等插件文件层面的行级归属IDE 内面板日常浏览代码时查看归属不适合汇总个人建议日常自己查数据用 git log 一个小脚本就够了要给别人看、要截图汇报用 GitStats要评估现有仓库规模用 cloc。尽量别在插件里面找“年度汇总”按钮你把精力花在读懂 git log 的输出上收获会大得多。3. 统计口径为什么同一个仓库能跑出三种结果3.1 commit 粒度与 diff 行数先认识 git 统计的基本单位。git log --shortstat里输出的“5 insertions() 3 deletions(-)”表示的是某次提交相对于它父提交产生的新增和删除行数。这个数字基于 diff 算法按行比较不按字符比较。所以一个关键结论git 统计的是“变更”不是“当前有多少行”。哪怕你只是把一行代码从文件底部挪到顶部diff 也可能算出 1 insertion 和 1 deletion。如果一次提交里把整个文件的行尾从 LF 换成 CRLF统计结果会爆炸式增长因为每一行都被判定为新增和删除。另一个很多人忽略的问题同一行代码被改动一次统计里就记一次新增加一次删除。假设同一行在今年被三个人各修改了一次它会计入三对增删。这没问题因为“变更量”本质就是这样定义的。但是如果你想统计“最终代码库的规模”这个指标完全无效——这就是为什么不要让 git log 和 cloc 混为一谈。3.2 合并提交、cherry-pick 与重复计算代码量统计最大的水分来源是合并提交和跨分支复制。默认情况下git log --shortstat并不会为合并提交输出 diff 统计因为它有一个父提交以上git 默认不展示合并提交的 diff。但如果你用了-m参数git 会把合并提交和每一个父提交分别比一遍那就会产生多份 diff统计结果瞬间膨胀。所以普通统计请在命令里加上--no-merges只统计普通提交。还有 cherry-pick 问题。如果一个 commit 从 feature 分支 cherry-pick 到 release 分支它在这两个分支上各出现一次。你在 release 分支上统计时会把这个 commit 完整算一遍在 feature 分支上再统计一遍又会算一次。如果你只是想统计“这段代码是谁写的”这没什么问题如果你想统计“今年产生了多少行新代码”重复提交会让数据虚高。分支合并带来的另一个问题是如果你在master分支上跑统计而团队的开发流程是“develop 分支合回 master”那么所有经过 merge 进入 master 的功能代码都不会被--no-merges的常规统计捕获。这种情况下正确的做法是在实际开发分支上统计或者使用git log --first-parent来追踪主干合入记录。这个问题几乎每个团队都会踩我认为是整个代码量统计中最需要提前想清楚的坑之一。3.3 作者与提交者、时间与时区git 里一个提交有两类身份Author 是代码的原始作者Committer 是把这个提交实际写进仓库的人。自己提交自己的代码时二者相同在git rebase、git commit --amend、或者由 CI 机器人代为提交时二者就会分离。--author过滤的是 Author--committer过滤的是 Committer。如果你想统计“谁写了这段代码”用--author如果你想统计“谁把代码合进来的”用--committer。举一个真实例子组里有个自动化工具会把所有人的改动整合后统一提交Committer 都是机器人账号。如果用 Committer 统计你会发现自己提交次数为 0用 Author 统计才正常。时间和时区也需要留意。--since和--until默认按本地时区解析但提交记录的时区存的是作者提交时的本地时区。如果你的时间过滤字符串是--since2024-01-01而某次提交的 Author 时区是 UTC8git 在比较时会做时区换算。简单结论跨年统计不要纠结边界上的那一两笔提交时区造成的偏差通常可以忽略但在精确到“某天”的统计里记得留意仓库里的提交时区设置。4. 实操方案单仓库与多仓库的代码量统计4.1 一条命令搞定个人季度代码量先用最日常的需求开头统计我自己在某个时间段写入了多少行代码。我通常用这组命令git log --author你的名字 --since2024-01-01 --until2024-03-31 --no-merges --oneline --shortstat输出结果包含了每一笔提交的次数和行数变化但需要汇总。我写了一个比较通用的 awk 聚合命令git log --author你的名字 --since2024-01-01 --until2024-03-31 --no-merges --oneline --shortstat | awk /^[0-9a-f]{7,}/ { commits } /files? changed/ { split($0, a, ,) for (i in a) { if (a[i] ~ /insertion/) { gsub(/[^0-9]/, , a[i]); insert a[i] } if (a[i] ~ /deletion/) { gsub(/[^0-9]/, , a[i]); delete a[i] } } } END { printf commits: %d, insertions: %d, deletions: %d, net: %d\n, commits, insert, delete, insert - delete }解释一下这个脚本的逻辑git log 输出的每一笔提交是一行 hash 提交信息紧接着一行 shortstat 摘要。awk 遇到以至少 7 位十六进制字符开头的行就把 commit 计数加一遇到包含 “files changed” 的行就把它按逗号切分成几段从中提取 insertions 和 deletions 的数字。最后输出提交次数、总新增、总删除和净增。我在实际使用中发现这个脚本可以满足 80% 的个人统计场景。如果提交信息很长、hash 缩写位数变化正则[0-9a-f]{7,}都能兼容。唯一要注意的是如果你的提交信息碰巧由数字开头并且恰好有 7 位以上这个脚本可能误判。解决办法是改用--prettyformat:%h明确提交行格式但日常使用中出现这种误判的概率很低。4.2 按文件维度统计热点代码有时候你不能只看总量还得知道“哪些文件被改得最狠”。这时候用--numstat更合适。它输出的每一行是“新增行数、删除行数、文件路径”非常适合按文件聚合。基础命令git log --no-merges --numstat --prettyformat: --since2024-01-01 --until2024-12-31 --author你的名字注意--prettyformat:会把提交信息这一行去掉只保留 numstat 数据。然后用 awk 汇总每个文件的累计变更git log --no-merges --numstat --prettyformat: --since2024-01-01 --until2024-12-31 --author你的名字 | awk $1 ~ /^[0-9]$/ $2 ~ /^[0-9]$/ { added[$3] $1 deleted[$3] $2 } END { for (f in added) { total[f] added[f] deleted[f] } for (f in total) { print total[f], added[f], deleted[f], f } } | sort -rn | head -20这里 awk 判断前两个字段是否都是纯数字避免把二进制文件行显示为“-”和异常输出混进来。最后按总变更行数排序取前 20 个文件能很快发现热点模块。在我自己的项目里这个命令最有价值的发现是有些文件虽然提交次数不多但单次改动超过 1000 行这种“一次性大变更”往往是合并、格式化或大重构造成的会让评审难度暴增。看到这类数据后我会建议团队拆小提交把纯格式变更和业务逻辑变更分开。4.3 多仓库下的一键统计脚本很多人的开发工作横跨多个仓库比如一个后端服务、一个前端工程、一个公共组件库。逐个进入目录执行命令太麻烦我写了一个简单的 bash 脚本跑完所有子目录下的 git 仓库汇总各仓库的提交数和增删行数#!/bin/bash author${1:-你的名字} since${2:-2024-01-01} until${3:-2025-01-01} for dir in */; do if [ -d $dir/.git ]; then cd $dir result$(git log --author$author --since$since --until$until --no-merges --oneline --shortstat | awk /^[0-9a-f]{7,}/ { commits } /files? changed/ { split($0, a, ,) for (i in a) { if (a[i] ~ /insertion/) { gsub(/[^0-9]/, , a[i]); ins a[i] } if (a[i] ~ /deletion/) { gsub(/[^0-9]/, , a[i]); del a[i] } } } END { printf %d/%d/%d, commits, ins, del }) echo $dir: $result cd .. fi done把脚本保存为git-stats.sh执行bash git-stats.sh 你的邮箱 2024-01-01 2024-12-31即可。脚本里的${1}和${2}允许你传参不传就用默认值。输出格式是“仓库名: 提交数/新增行数/删除行数”一眼能看清每个仓库的贡献量。这个脚本我在多个团队里用过稳定性还不错。唯一的提醒是不要在仓库目录里直接运行另一个仓库的脚本时搞混当前目录脚本每次cd $dir后必须cd ..退回否则第二次循环会跑到错误目录。我一开始写脚本时漏了这个导致结果全是同一个仓库的重复数据。4.4 生成可视化报告与物理行数统计如果你要给领导做汇报纯文本输出可能不够直观建议用 GitStats 生成 HTML 报告。# 安装 pip install gitstats # 生成报告gitstats 仓库路径 输出目录 gitstats ./ /tmp/my-report生成的index.html里包含作者提交排行、每日活动、文件热图等图表是季度汇报的好素材。但还是那句老话它是基于整个仓库历史生成的不是按你的个人过滤。如果你只想展示某个人的数据建议先单独克隆一份仓库或者直接看第 4.1 节里的文本统计。如果想统计“当前代码库到底有多少行代码”用 cloccloc . --exclude-dirnode_modules,vendor,dist --include-langPython,JavaScript注意 cloc 统计的是当前工作区里所有文件的行数和 git 历史无关。它能按语言分类输出适合回答“改造前这个项目有多少行 Python、多少行 JavaScript”。配合 git 的变更统计就能从“存量”和“流量”两个维度完整描述一个项目。5. 统计前置条件提交规范和环境对结果的影响5.1 提交信息规范与统计过滤统计代码量听着像是技术活其实结果很大程度取决于团队的提交规范。提交信息写得不规范过滤就会变得很痛苦。比如你想区分“功能性提交”和“修 bug 的提交”如果团队里有人写fix: 修复登录超时有人写改了一下还有人一个巨型提交塞了三个功能你的统计就只能停留在“总代码量”层面无法往下拆分。如果团队已经使用 Conventional Commits 之类的规范你可以用--grep按提交信息过滤# 统计以 feat 开头的提交 git log --author你的名字 --since2024-01-01 --until2024-12-31 --grep^feat --oneline # 统计包含 fix 的提交及其代码量 git log --author你的名字 --since2024-01-01 --until2024-12-31 --no-merges --grep^fix --shortstat | awk ...没有规范也没关系统计前先花十分钟git log --oneline快速扫一眼提交信息的风格就知道哪些关键字可以用于过滤。我自己见过不少仓库 70% 的提交信息都是update、test、merge这种仓库里的“按功能类型统计”基本没法做。想改善这一点只能靠提交规范推广。还有一个容易忽略的点git commit --amend会修改提交信息、改动提交哈希和时间线。如果团队里有人频繁 amend 已经推送的分支你在--since时间过滤时会看到提交时间往后“漂移”了导致某段时间的统计数字奇低。这不是统计工具的问题是提交历史已经被重写过了。所以如果你的统计周期是精确到“某一天”的最好先确认这段时间内有没有人重写过历史。5.2 分支合并和子模块带来的统计陷阱分支模型对统计结果的影响我在第 3.2 节提过一部分。这里补充一个常见的具体场景有人直接在master上统计结果发现自己的代码量为 0原因是他所有的提交都先在dev分支上完成最后通过 merge 操作合入master而--no-merges把合并提交排除掉了。正确的做法之一是在你的日常开发分支上统计而不是在合并目标分支上统计。如果你已经形成了固定的分支命名习惯比如feature/*可以在命令里加路径过滤或分支过滤git log --author你的名字 --no-merges --since2024-01-01 --until2024-12-31 --shortstat feature/my-module子模块也值得单独说。主仓库里引用了 submodulegit log在主仓库内只能看到 submodule 指针的变化看不到子模块内部的代码提交。要统计子模块的代码量必须进入子模块目录单独跑统计。我第一次统计一个含子模块的项目时漏掉了所有子模块的数据最后总量少了差不多三分之一。5.3 快捷环境检查认证、过滤文件与目录安全在开始统计之前建议顺手做几个环境检查避免跑一半才发现仓库状态不对。第一是认证问题。统计本地历史其实不需要认证但如果你需要先git fetch拉取最新分支或者用脚本从远端克隆仓库就可能遇到 SSH 认证失败。遇到的时候先验证一下ssh -T git你的代码托管平台地址确认公钥配置正常也可以用 HTTPS 协议加 token 代替 SSH。这个排查顺序基本能解决 90% 的认证问题。第二是过滤文件。很多人以为.gitignore能影响 git 统计实际上它只作用于“尚未被跟踪的文件”。如果某天你把dist或node_modules提交进了仓库之后就算在.gitignore里加上它们也没用因为它们已经被 git 跟踪了。要恢复得靠git rm -r --cached dist把文件从索引里移除。这个坑在统计时尤其致命如果你统计的仓库里 isset 早前误提交了大量依赖目录任何代码量统计都会被这些第三方文件淹没。第三是目录安全。近两年经常能看到“git 目录泄露”相关的话题本质是网站把.git/目录暴露在公网导致源码被下载。作为开发者比起研究怎么下载别人暴露的仓库更应该先检查自己的服务器是否拒绝外部访问/.git/路径避免代码被爬走。统计代码量和这个没有直接关系但仓库一旦泄露后续的风险远大于统计数字本身。6. 常见问题与排查技巧实录6.1 问题速查表我在帮同事调试统计命令时攒了不少典型问题先整理成表格现象可能原因解决办法统计结果比别人少很多统计口径不同比如排除了合并提交、过滤了某些作者、时间范围不同统一明确参数对比时先确认双方使用的命令一致统计结果虚高仓库里包含 dist、node_modules、vendor 等目录用-- path过滤路径或先git rm -r --cached掉误跟踪的目录用 --author 查不到某个人的提交提交人改了邮箱或者提交作者名和显示名不一致用git log --format%an %ae查看完整作者信息提交信息中文乱码终端编码问题和 git 的路径转义执行git config --global core.quotepath false把终端设为 UTF-8Windows 下命令行跑 awk 报错PowerShell 管道和 awk 兼容性差使用 Git Bash 执行不要在 PowerShell 里直接跑复杂管道统计时偶尔出现 “git open /dev/null or dup failed” 相关报错系统默认 shell 或终端工具链异常检查 SHELL 环境变量尽量在 Git Bash 或标准终端里操作只读命令总仓库跑 GitStats 非常慢仓库历史太长提交次数过多先用小仓库或--since过滤测试生成报告时可排除某些目录6.2 踩坑记录与个人心得多讲几个我在实际统计过程中印象比较深的细节。关于“作者名查不到”的问题。git 的 Author 并不总是等于你在托管平台上的用户名。有人本机配置的是user.name昵称邮箱是临时邮箱后台统计系统按邮箱归一你按名字一查发现统计结果为零。碰到这种情况建议先跑一句git log --format%h %an %ae --since2024-01-01把仓库里真实出现的作者名和邮箱列出来再去写过滤条件。关于“大文件提交失败”和统计的关系。很多团队会遇到git 无法提交大文件的问题比如资源文件超过托管平台限制。处理这类问题通常建议接入 LFS而不是把大文件塞进普通 git 仓库。从统计角度看大文件一旦被提交进仓库虽然不会直接增加代码行数但会让git log遍历历史变慢还会让 clone 体积膨胀。所以遇到仓库越来越慢的时候第一件事不是优化统计命令而是查一下历史里有没有混入大文件。关于“提交次数”和“代码行数”的错位。git shortlog -sne显示的提交次数高不代表代码量就大。有的人习惯小步提交一天提交 20 次有的人一个大功能写完才提交 1 次。这两种人的 shortlog 排名差异很大但代码量可能差不多。所以做团队对比时我通常会同时看提交数和变更行数不能只用一个指标下结论。还有一个让我印象很深的教训在一个历史较长的仓库里直接用git log --author... --since...统计时没有加--no-merges结果多统计出接近一倍的代码量。排查后才发现那个仓库的合并策略会把所有功能分支的变更在 merge 提交里再算一遍等于把原有代码量重复计了一次。所以“统计前先想清楚要不要排除 merge 提交”这句话我几乎每次都会对同事重复一遍。最后如果你发现一个仓库的代码量统计结果和预期差异极大不要急着怀疑工具。先跑一下不带任何过滤条件的git log --oneline | wc -l看看总提交数再逐步加过滤条件对比数字变化。这种“逐步缩小范围”的排查方式比直接看最终统计结果有效得多。我个人在实际工作里已经习惯把统计命令做成一个简单的 shell 脚本每次需要时传入作者和时间范围几秒钟出结果。用多了之后最大的感受是代码量数据最动人的地方不在于它证明你写了多少行而在于它能帮你回顾某一段时间的修改节奏。比如我去年年末复盘时看到某个模块在两周里被连续修改了二十多次才发现当初的抽象设计没做好。这个信号远比“我写了八万行代码”这句总结有实际价值。