数完自己仓库我改口了：87.3% 的提交不是人写的
Hello，我是飞飞。
10 月 6 号，GitHub 发了篇工程博客，主题是为 agent 规模重建 Git 的底层基础设施。开篇第一句就是：agent 驱动的软件开发，正在带来下一次架构级的迁移。
我看完的第一下，是心里咯噔。因为三个半月前，我专门写过一篇，讲「要不要给 agent 换掉 git 的底座」。当时的结论是先不换，我守着这条 git 主线。而我数完自己的仓库才发现，最近这一段的提交里，87.3% 的署名不是我。
你要是也天天让 agent 干活，回头数一下自己的仓库，这个数大概率也不低。
现在有人真动手了。而且不是 GitHub 一家。
这篇我想把两件事摊开看：GitHub 拆了什么，这个 87.3% 又是怎么长出来的。
两家平台同时拆了地基
先给数。
GitHub 说，全平台的 Git 活动量，从 2025 年 9 月的 2182 亿次，涨到 2026 年 8 月的 4733 亿次，翻了一倍以上。注意这个口径：是「全平台的 Git 活动总量」，既不是提交数，也不是推送数。原文没有定义「活动」到底包含哪些操作，那我就照它的措辞写，不替它拆解。
另外两个数更贴地。提交量，2026 年 9 月是 73.8 亿次。原文的说法是「开发者和 agent 一共」。GitHub 没把这两拨拆开，我一个字都不替它猜。
推送量，从每月 6.9 亿次涨到 33.5 亿次，同比 4.9 倍。注意，这是推送的次数，跟多少人在推是两回事。
GitHub 直说：agent 驱动的开发，是这次架构迁移的推手。但所有增长倍数用的都是「人和 agent 合计」的口径。所以我能写「同期涨了」，不能写「因为 agent 所以涨了这么多」。
最有信息量的一条在这儿。GitLab 早在 2026 年 5 月就宣布了同一件事。它 CEO 在内部信里的原话是「Git 本身正在为机器规模重做一遍」。交给 SEC 的文件里写的是「一个为 agent 造的新 git，能撑住机器规模」。官方博客上的说法是「一个为 agent 规模并发而重建的 Git 引擎」，现在还在私有测试。
两家是正面竞争对手，在同一段时间里各自去动同一个最底层，用词几乎能互换。判断真趋势，我有一把笨尺子：看对手肯不肯往同一个方向掏大钱。这次两家都掏了，而且是维护性的钱。这种钱最难掏，因为花出去没人给你鼓掌。
而且 GitLab 比 GitHub 早五个月。
一笔账为什么要五人会签
GitHub 这篇里最硬的一句是这句：我们用来做持久化的机制，和用来做扩展的机制，是同一个。
现在每个仓库，默认在五台文件服务器的本地盘上，各留一份全量副本。这五份身兼三职：冗余、扛读、以及参与每一笔写。
写成大白话就是：一笔账要五个人同时签字才算数。他们都在，这叫冗余；他们都能把账拿给人看，这叫扛读；每一笔改动他们五个都得签，这叫参与写。
麻烦就出在这。你想给读加容量，多找一个人来看账，那么每笔账也跟着多签一个人，写反而更慢了。反过来，少一个人，读的容量就少一块。人要是凑不齐一半，整个写就停。
为 A 目的买的保险，成了 B 目的上的税。
这句 GitHub 没写过，是我自己读出来的。它讲的不只是 Git 的事：你在系统里把一个部件赋予两个目的，早晚会有一个目的把另一个拖死。
GitHub 的解法是把这三件事拆开：权威数据挪到云存储上，只管持久化；读交给只做缓存的轻量进程；维护性的活挪出服务主机。它自报的写吞吐，最高提升 35 倍。
这个 35 倍我得标清楚：是 GitHub 自己内部跑出来的，没有经过第三方独立复现，原文也没说自己怎么测的。听方向可以，别当铁的。
我先数了自己那个仓库
两家都在拆地基，那我自己那条线呢？
三个半月前我写的那篇，主角是一个叫 Oak 的开源项目，它想给 agent 换掉 git。它戳的那个痛点我认：agent 把 git 历史写乱，我天天亲历。但最后我说，不换，至少现在不换。理由很现实，就一个字，贵。我这条写作流水线挂着十几个 skill，每一个都是顺着 git 那套规矩磨出来的。那工具当时又还是 v0.99.0 的公测版，我的真实仓库不会拿去给它当小白鼠。
现在 GitHub 和 GitLab 两家，等于替我把这个底座动了。换成你，大概也会想：那等着就行？
这念头我也冒出来过。我原以为有「人确认了才落进主线」这条规矩拦着，那条线上写东西的主要还是我。于是我把仓库打开，数了一遍。
这个仓库 2022 年建的，到今天一共 607 条提交。带 Claude 署名尾注的，424 条，占 69.9%。
但总数不重要，重要的是切开看。我拿 6 月 23 号那篇当刀口，那是我写下「先守着 git」的那天。再往前的我没算，跟这次对比无关。
刀口之前，2026 年 3 月到 6 月 23 号，288 条提交，带 agent 尾注的 177 条，61.5%。
刀口之后，6 月 24 号到今天，283 条提交，247 条带尾注，87.3%。
最近 7 天，9 条提交，9 条都带。
我当时把话说得太满了
数出这个 87.3%，我翻回 6 月 23 号那篇，确认自己真写过那句话。
当时我在复述 Oak 作者那套思路：agent 每落一次提交都会污染历史，开销也大。正确的做法是把 agent 的工作流跟 git 解耦，让它先在自己那层折腾，等人确认了才落进给人看的那条主线。
这句话我是认的。我甚至拿它当自己的路线。
三个半月后，底座我确实没换，这条线我也没拆。线还在原地，提交量也还是那个量，288 条对 283 条。变的只是署名：带 agent 尾注的，从 61.5% 变成了 87.3%。
更能说明问题的是两个提交之间的间隔。
我翻了最近的记录。10 月 7 号 15 点 41 分 02 秒，一条提交，写的是新文章出稿。15 点 41 分 04 秒，第二条，写的是这轮提炼出来的写作经验入库。两条之间差 2 秒。
10 月 6 号那次差 7 秒，10 月 4 号两次分别差 8 秒和 4 秒。
一次流水线跑完，自动落两个提交，中间连你伸手的功夫都没有。
还有一处，我翻配置才想起来。项目设置里早就预批了两条权限，git 暂存和 git 提交，agent 可以直接用，不用逐次问我。
我说的「人确认了才落进主线」，在起点上还成立。选题要我拍板，发公众号要我点头，这两道闸我守着呢。可「确认」这个动作，在我这儿慢慢从当场的动作，变成了事前的授权。
我现在的提交长什么样
那这算翻车吗？我想了想，也不算。
它只是让我看清一件事：「人确认后才落进 git」这句话，守的方向是对的，守的量没守住。规矩一个字没改，改的是它每天放 agent 多少东西过去。
而且三个半月前那篇，我留了个问题没答。结尾我写的是：你让 agent 改代码的时候，是宁可它一路别提交、最后自己收尾，还是宁可它一步一个 commit、把历史写成流水账？当时我说，这两种我都试过，没拿定主意。
现在回头看，我走的是第三种。那两种我都没选。
我让 agent 照常频繁提交，但每条提交得长成一个样子：我自己定的一套类型前缀，加一行署名尾注。
我最近三十天用的前缀大概是这几类。post: 是发了新文章；chore(training): 是这轮提炼的写作经验入库，最新已经是第一百九十六次；docs(geo): 是 GEO 台账；fix(distributor): 是分发脚本修了 bug。
所以规矩不是「提交几次」，是「提交长什么样」。
这三个半月里，这条线上一共走了 283 条提交，其中 247 条不是我自己一个个敲出来的。但那 247 条，每一条都套着我自己定的那身衣服。
那条线现在还有谁在读
我三个半月前担心的是「主线会被 agent 写乱」。数完才发现，乱不乱其实是小事。真正变了的是另一头：那条给人看的主线，现在还有谁在读？
我自己的答案有点扫兴，读的人少了。我出稿前基本不翻 git log，反正每条提交长什么样都是我定的规矩，扫一眼就知道流水线干了什么。它现在更像一本流水账，不太像一封信了。
我这条规矩也在犯那个毛病：一个部件，两个目的，早晚有一个目的把另一个拖死。它一直是道质量关，拦着不该进主线的改动。它还替我看住另一件事：每签一次，就等于我在那条线上露一次脸。到今天，当质量关的那半截仍然管用，只是「我还在场」这半截，已经没人查了。
所以我今天想给你一个成本极低的动作：打开你自己的仓库，跑一次 git log，数一数带 agent 署名的提交占了多少，最近七天又占多少。数不出来也行，那个数本身就是答案。
我自己那套规矩（类型前缀加署名尾注）就在上面，你要抄随时抄。
GitHub 说这是他们系列的第一篇，下一篇才讲细节。他们那边还在施工，我这边也一样，这条线该怎么走，我还得接着看。
你数完自己那条主线，那个数比你以为的高，还是低？