不用装任何第三方统计平台也不用逐个 commit 数数。git 本身就是最好的代码量统计工具关键是你得知道怎么让它开口说话。写简历要填代码量、季度述职要讲产出、跳槽面试被问“你平均每天提交多少次”这种需求我碰到太多次了。这篇文章直接把我这几年在实际项目里验证过的统计方案写出来从最基础的 git log 命令到能直接出报表的工具最后再聊聊代码量统计里那些容易翻车的坑。1. 统计前先想清楚你的代码量到底指什么很多人上来就跑git log | wc -l数了一堆提交记录然后发现数字根本没法用。问题不在命令而在你没定义清楚“代码量”。先想明白这个问题后面的统计才有意义。1.1 统计口径决定了结果的用途代码量通常有三种口径对应完全不同的统计方式。第一种是提交次数commit 数衡量的是“动了多少次手”。适合看开发频率和活跃度不适合衡量工作量因为一次提交可能只改了 1 行也可能改了 5000 行。第二种是增删行数added/deleted lines这是最常被拿来当“工作量”的数字。git log配合--numstat或--shortstat就能拿到每个提交的增删行数净增代码新增行数减去删除行数才是大多数人真正想要的数字。第三种是当前存量现有代码行数也就是仓库里现在一共有多少行代码。这个用cloc这类工具最合适它反映的是“目前项目的规模”跟某个人写了多少没有直接关系。我实际统计时基本都用第二种净增行数。它最能说明“你为代码库带入了多少内容”同时也能暴露你把代码改少了还是改多了的事实。但我建议你在心里把三种口径都算一遍因为不同场合要用不同数字。1.2 统计范围也得先圈定范围问题没搞清楚统计结果会错得离谱。先说仓库范围。你现在所在的本地仓库是不是完整体如果是用git clone --depth 1拉下来的浅克隆历史提交只有最近一条任何历史统计都会失真。用git rev-parse --is-shallow-repository查一下返回true的话得先补全历史git fetch --unshallow。再说分支范围。默认git log只统计当前分支的历史可你上个月部分工作可能还在别的分支上。要用git log --all把所有分支都算进来或者明确指定分支名。然后是时间范围。年度述职、季度小结都要靠--since和--until两个参数圈定时间段我下面会给出具体的时间写法。最后是作者范围。git 的 author 跟 committer 是两个身份默认统计按 author 来实际使用中记得统一用--author。2. 不装工具用 git log 和 git diff 也能统计我自己在统计单仓库时超过一半的情况不会开任何第三方工具。git 原生命令已经能把数据给得很细只是输出格式有点“原始”需要稍微处理一下。2.1 先摸清家底提交数和作者排名想知道一个仓库里一共多少提交、哪个作者提交最多两行命令就够# 当前分支总共多少个提交 git rev-list --count HEAD # 每个作者的提交次数和排序 git shortlog -sn --allgit shortlog -sn的输出长这样128 张三 96 李四 31 王五这个数字可以快速判断团队协作结构。如果发现一个项目里某个人的提交数占掉了 70%你基本能猜到这是个“个人项目”而不是“团队项目”。2.2 用 --numstat 拿到每次提交的增删行--numstat是统计增删行的核心参数。它会把每个提交涉及的文件、新增行数、删除行数都列出来格式类似12 3 src/main.py 0 3 README.md前面的数字是新增行数后面是删除行数最后一列是文件名。-表示二进制文件不计入文本统计。光看输出没啥用得用 awk 累加。比如统计张三在所有分支上面的总增删行git log --all --author张三 --prettytformat: --numstat \ | awk { add $1; del $2 } END { printf 新增: %d 行, 删除: %d 行, 净增: %d 行\n, add, del, add - del }这里--prettytformat:是为了把提交信息的标题、时间这类内容清空只留下--numstat产生的数字。很多人会漏掉这个参数结果 awk 把乱行也算进去统计自然就错了。2.3 按日期范围筛选周报、月报、述职都能用如果只想统计某个时间段的工作量加上--since和--until就行了git log --author张三 --since2024-01-01 00:00 --until2024-06-30 23:59 --prettytformat: --numstat \ | awk { add $1; del $2 } END { printf 新增: %d 行, 删除: %d 行, 净增: %d 行\n, add, del, add - del }这几个参数都吃相对时间所以你也可以写--since3 months ago、--sincelast month。我个人的习惯是写绝对时间因为相对时间受执行当天日期影响万一自己存了脚本下个月跑结果居然变了容易出乌龙。3. 三个能直接抄的统计脚本光会敲单条命令还不够实际到了季度汇报或者简历更新这种大场景你需要一套能反复出数的脚本。下面这三个脚本我都跑过直接拿过去改改名字就能用。3.1 单仓库单人净增代码统计这段脚本适合算“某个人在当前仓库整体贡献了多少”。我把上一节的命令稍微包装了一下加了只有增删行统计#!/bin/bash AUTHOR${1:-张三} REPO_PATH${2:-.} cd $REPO_PATH if [ ! -d .git ]; then echo 错误: $REPO_PATH 不是合法的 git 仓库 exit 1 fi git log --all --author$AUTHOR --prettytformat: --numstat \ | awk { if ($1 ! - $2 ! -) { add $1; del $2 } } END { printf 作者: %s\n新增: %d 行\n删除: %d 行\n净增: %d 行\n, author, add, del, add - del } author$AUTHOR这里我特意判断了$1 ! -和$2 ! -把二进制文件跳过。有些 CI 产物、图片、字体文件一旦被提交进去会在 numstat 里显示成-如果不过滤awk 会把-当成 0 来相加还好但更坑的是它会影响行数对齐导致累加结果异常。3.2 多仓库合并统计一个 for 循环搞定手头项目多的人通常不是在一个仓库里工作而是分布在十几个仓库。这种时候我会先批量把仓库目录都存到.repos.txt文件里然后循环统计再汇总#!/bin/bash AUTHOR${1:-张三} TOTAL_ADD0 TOTAL_DEL0 for repo in $(cat .repos.txt); do if [ -d $repo/.git ]; then result$(git -C $repo log --all --author$AUTHOR --prettytformat: --numstat 2/dev/null \ | awk { if ($1 ! -) add$1; if ($2 ! -) del$2 } END { print add, del }) add$(echo $result | cut -d -f1) del$(echo $result | cut -d -f2) echo $repo: $add/-$del TOTAL_ADD$((TOTAL_ADD add)) TOTAL_DEL$((TOTAL_DEL del)) else echo 跳过 $repo: 不是 git 仓库 fi done echo echo 合计: 新增 $TOTAL_ADD 行, 删除 $TOTAL_DEL 行, 净增 $((TOTAL_ADD - TOTAL_DEL)) 行git -C $repo是我常用的参数不用先 cd 进目录再执行命令循环里面特别省事。2/dev/null把可能出现的仓库损坏提示或者空仓库错误吞掉避免脚本中断。3.3 统计时排除锁文件和生成物项目里总有一些“看起来是代码实际不是代码”的文件最典型的是package-lock.json、yarn.lock、go.sum、各种dist目录。它们动辄几千行而且一改就是一大片会把你的真实代码量水分很大。要排除它们用 pathspec 的 exclude 语法git log --all --author张三 --prettytformat: --numstat -- . :!package-lock.json :!dist/** :!vendor/** \ | awk { add $1; del $2 } END { printf 净增 %d 行\n, add - del }:!pattern是 git 的 exclude pathspec 写法星号通配符也能用。注意这里不能偷懒只写.gitignore因为.gitignore只对未被跟踪的文件生效一旦某个生成文件已经入库跟踪了git log 照样会统计它。我在一个项目里就吃过这个亏dist目录早年被提交过导致每月统计都多出小一万行排查半天才定位到。4. 图省事就上工具gitstats、cloc、git-quick-stats如果上面的脚本你觉得太糙、排版难看或者你想把统计结果直接给团队看那就得上工具。这几年我用下来最顺手的就三个各有各的适用场景。4.1 gitstats一键生成可视化报表gitstats 是一个生成 HTML 报表的工具输入仓库路径和输出目录它会把代码量、活跃度、提交时间分布、作者贡献这些信息全做成静态网页。适合想给领导展示的情况打开浏览器就能看。在 macOS 上安装brew install gitstats生成报表gitstats /path/to/repo /path/to/output它会生成index.html和一堆图表。我常用的页面是“Commit activity”和“Authors”两个前者看提交节奏后者看各作者的行数占比。gitstats 的问题在中文支持一般如果 commit 信息里全是中文某些页面可能乱码需要留意。4.2 cloc统计当前仓库的存量代码量cloc 是另一个方向的工具它不关心历史提交只统计“现在 checkout 出来的这份代码一共有多少行”。它支持语言识别能区分 Python、JavaScript、Java、Go 等上百种语言。安装方法# macOS brew install cloc # Ubuntu / Debian sudo apt install cloc基本用法cloc .输出大概长这样------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- Python 128 4231 1132 15230 JavaScript 96 2611 984 11288 Shell 18 320 154 982 ------------------------------------------------------------------------------- SUM: 242 7162 2270 27500新增的 DSL、Markdown、JSON 这些都默认会算进去。如果只想看特定语言cloc . --include-langPython,Gocloc 适合回答“这个项目有多大”不适合回答“张三写了多少代码”——它不是按 Git 作者维度来统计的。我会用 gitstats 或 git log 算人的工作量再用 cloc 算项目总体量两者结合着对比才能判断一个人在这堆代码里的占比是否合理。4.3 git-quick-stats一个交互命令搞定日常查询git-quick-stats 是 GitHub 上一个开源工具它的特点是把常见的统计场景做成交互菜单。装上之后输入git quick-stats会出现“1. 贡献者排名 2. 提交时间线 3. 某作者增删统计……”等选项选数字就能出结果。安装方式brew install git-quick-stats它内部就是封装了各种 git log 的组合参数。我把它当成“不想背命令时的替代品”尤其适合同事临时让我帮统计一下某某的工作量时我直接在仓库里跑一下菜单几秒钟给出结果比自己敲 awk 命令快多了。工具终究是工具核心原理还是那句git log 给原始数据awk 做累加可视化只是包装。理解了底层工具换什么牌子都不慌。5. 统计时容易踩的坑我一个个记下来上面讲的主要是“怎么做”下面得讲讲“哪里容易栽”。我统计过几十个大小仓库几乎每个仓库都会冒出至少一个坑提前避开能省很多时间。5.1 merge 提交会让行数重复计算merge 提交的本意是把别人的分支合并进来但它自身也会产生增删行的“假象”。如果你用git log --all不带任何过滤条件merge 产生的提交很可能会把同一批代码的行数算两遍一遍在源分支一遍在 merge 提交里。我验证过最极端的情况一个仓库用--numstat直接统计总行数结果是当前代码存量的 3 倍多罪魁祸首就是 merge 提交的叠加。解决方法是统计个人工作量时跳过 merge 提交git log --all --author张三 --no-merges --prettytformat: --numstat5.2 重命名文件会造成增删虚高把user_service.py重命名为person_service.py这种事太常见了。Git 的默认输出会把这次操作识别成“删了一个文件、加了一个文件”于是你的删除行数和新增行数各自暴涨几百行净增却几乎为 0。如果不想被这种操作误导加-M开启重命名检测git log --all --author张三 -M --prettytformat: --numstat-M默认认为内容相似度在 50% 以上的两个文件是重命名不会把它们当成删除加新增。也可以写成-M20%调低阈值不过实战里默认值够用了。5.3 浅克隆和镜像克隆的差别前面提过--depth 1的浅克隆只会带最后一条提交记录历史全被截断了。对于要统计的仓库请优先用完整克隆。如果只需要代码不带工作目录用--bare镜像克隆会更省空间git clone --bare https://example.com/repo.git裸克隆的结构是纯.git内容没有工作区拉历史记数据足够用了。很多 CI 环境里预置的仓库经常是浅克隆跑统计前务必确认否则数字低得离谱还不知道为什么。5.4 二进制文件会把统计带偏图标、字体、Excel 表格、PDF这些东西一旦进仓库--numstat会显示为-awk 按行加的时候问题不大。但 cloc 这类按语言识别的工具会直接跳过二进制。问题在于像.min.js这种压缩后的 JS以及各种自动生成的 lock 文件它们能被识别成文本但内容是人看不懂、也没必要统计的“机器产物”。我的做法是分两层过滤外层用 pathspec 排除锁文件和生成目录内层用--numstat的-判断排除二进制。两层齐下数字才干净。5.5 SSH 认证失败和 git 目录不全的问题统计的前提是你得能拉到完整仓库。有时候git pull报ssh: connect to host ... port 22: Connection timed out或者Permission denied (publickey)这跟统计本身无关但会卡住后面的所有步骤。我遇到 SSH 认证失败时解决思路通常是三步第一步确认 SSH key 是否添加ssh-keygen -t ed25519 -C your_emailexample.com ssh-add ~/.ssh/id_ed25519第二步在 Git 托管平台上把公钥填入 SSH keys。第三步本地验证连通性ssh -T gitgithub.com如果输出里带你的用户名说明认证通了。这一步走通后面拉仓库、统计才有原料。另外如果是从别人那里拷贝的仓库目录.git目录缺失或者被截断任何统计命令都会直接失败别浪费时间去调试先重新 clone 一份完整的。5.6 commit message 不规范统计也可能对不上我见过有人用git commit -m wip提交了几十次后面想按功能统计代码量时彻底抓瞎。虽然行数统计不需要读 commit message但如果你想把代码量和某个功能、某个阶段对应起来没有规范的 message 就是一场灾难。如果已经提交了但 message 写得烂可以用git commit --amend修改最近一次的注释还没推送到远程之前是可以随便改的git commit --amend -m feat: 完善用户模块的错误处理已推送的不要硬改会污染共享历史。最好的做法是从一开始定好提交规范比如采用feat:、fix:、refactor:这种 Conventional Commits 格式后面统计哪部分改动都属于哪个功能git log --grep一搜就全出来了。6. 数字到手以后怎么读才不被领导或面试官打脸统计出几十万行代码以后先别急着发朋友圈。代码量这个数字单独拎出来说事信息量其实很低关键看你拿它去干什么以及怎么解读。6.1 行数从来不等价于工作量同样是“净增 5000 行”可能是花两周写了一个全新的核心模块也可能是一天里 IDE 自动格式化了整个代码库或者把一段重复代码复制粘贴了 10 份。反之一个人辛苦重构了一个模块删了 8000 行、加了 3000 行净增是负的但他的价值可能比写 2 万行新代码的人更高。我现在的习惯是不要把净增行数直接报成“我写了多少行”而是拆开说“我重构了哪些模块、新增了哪些能力和对外的接口行数变化大概是多少”。行数是论据不是结论。6.2 三组辅助指标一起看才靠谱与其死盯行数我更推荐同时看三组指标提交频率每天、每周平均几个 commit、提交间隔最长多久没提交和单次提交的规模中位数而不是平均数因为平均数会被那几个巨大的格式提交带偏。看一下某人最近 30 天的提交密度git log --author张三 --since30 days ago --prettyformat:%h %ad %s --dateshort输出是一列日期和 commit 信息你自己一眼就能判断出工作节奏。如果日期集中在最后两天说明这人是 Deadline 前突击提交的“脉冲式开发”跟稳定迭代的人相比代码量的含金量完全不是一个等级。6.3 写简历和汇报的三个建议第一个建议用“现有存量 个人净增”的组合代替单一数字。比如“参与维护的代码库约 2 万行主责模块净增约 8000 行”比“我写了 8000 行”可信度高。第二个建议报数字时带上时间区间让数字有上下文。“2024 年 H1 净增 1.2 万行”比“一共写了 1.2 万行”更能体现迭代速度。第三个建议务必自己先手工核对一遍目标仓库挑几个最近的重点提交跟脚本结果对一下。我见过不少数字对不上的人面试官一问“你说你写了这几个模块但 git log 里怎么搜不到”就直接露馅了。代码量统计的价值恰恰在于——它是你真实工作轨迹留下的证据数据会老实说话。我个人的体会是代码量统计最大的价值不是拿去给别人证明什么而是拿回来给自己看。它能够帮你复盘过去一个季度我到底把时间花在了哪里是写了大量新功能还是在反复修同样的 bug或者只是做着大段大段的格式整理。照着 git log 输出里那些文件路径逐月过一遍你会发现很多当时觉得很忙的日子其实并没有给代码库带来多少积累。反过来那些真正推进了项目的时刻通常数字不大却改变了代码的结构和质量。优化好这个过程统计才会有意义。