10,000条提交记录里，2,300条在集体装死。
开发者 Tim 跑了个脚本，扒了50个开源仓库的提交历史。结果像一盆冷水——近四分之一的消息，读完和没读一个样。你盯着"fix""update""wip"这种单字谜语，仿佛在考古现场挖到一张空白纸条。更魔幻的是，有人干脆敲个"."就提交了，像在给代码库打摩斯电码。
Tim 的统计清单堪称行为艺术：fix、update、wip、.、changes、stuff、misc、asdf。最后那个"asdf"大概是键盘上随手滚了一圈。这些不是恶作剧，是真实存在于生产环境的提交记录。当你凌晨三点被叫起来排查线上故障，翻到这条"fix bug"，想顺着网线过去问问具体修了哪个 bug——却发现作者三年前已离职。
「努力过」的失败更气人
有些提交消息试图认真，但认真错了方向。"update readme""add feature""change config"——这三个短语像超市促销标签，告诉你货架上有东西，但不说为什么摆、给谁用、解决了什么痛点。
Tim 画了一条清晰的界线：WHAT 和 WHY 之间隔着整个太平洋。"fix bug"是 WHAT，"fix: handle empty response from payment API gracefully"才是能救命的信息。前者让后人猜谜，后者让后人睡个好觉。
他举了个对比案例。烂消息："update"。好消息："feat: add email notification for failed builds"。后者用约定式提交（Conventional Commits）的格式，类型标签+具体描述+业务场景，三秒内你能判断这条改动会不会踩到你的坑。
Tim 的样本里，采用约定式提交的仓库，优质消息率达到82%；没采用的，54%。这28个百分点的差距，不是代码能力问题，是协作意识的代差。
一个 Python 脚本的「审判」
Tim 没停留在吐槽。他写了个开源工具 git-commit-analyzer，给提交消息自动打分。
核心逻辑粗暴有效：定义一组"废话词库"（fix、update、change、wip、stuff、misc），检测消息长度和关键词。少于两个词且命中词库？判为 vague（模糊）。空消息？直接 bad（不合格）。其余算 good（可用）。
脚本跑完输出一个百分比得分。Tim 建议把这个塞进 CI/CD 流水线——提交质量低于70%就阻断构建，从流程上逼团队长记性。配置只有几行 YAML，但杀伤力堪比代码审查。
这个设计戳中了一个老问题：技术团队的坏习惯，靠自觉改不了，得靠工具「羞辱」。就像单元测试覆盖率，你不量，它就永远「差不多行了」。
为什么程序员宁愿写「asdf」？
Tim 的数据没解释动机，但场景不难还原。赶 deadline 时，提交框像验证码一样碍事；个人项目里，「反正只有我看」；团队没规范，劣币驱逐良币，你写详细描述反而显得格格不入。
更隐蔽的原因是：写好的提交消息需要上下文切换。你刚调完一个棘手的 race condition，大脑还在内存状态里，手指已经本能地敲了"fix"。等你想补一句清楚的描述，Git 的默认编辑器可能还是 Vim，退出都要查教程。
约定式提交的价值在这里显现——它降低了「写好」的认知负荷。feat/fix/refactor/docs/test 六个前缀，像麦当劳的点餐编号，不用动脑子就能分类。剩下的精力专注描述 WHAT 和 WHY，而不是纠结格式。
Tim 的工具还做了时间模式分析。有些团队的提交质量随 sprint 周期波动，deadline 前一周断崖式下跌。这种数据比任何复盘会都诚实。
开源仓库的提交历史是技术债的化石层。Tim 扒的50个仓库里，有些早期代码像考古遗址，层叠着"wip""fix again""final fix""really final fix"的地层。后来引入约定式提交的团队，地层突然变得可读，像从乱葬岗切到了公墓区——至少每个坑位有墓碑。
这个对比让 Tim 的兴奋感有据可依。82% vs 54%不是抽象数字，是后人排查问题时少花的几百个小时，是 onboarding 新成员时少翻的几千条记录。
Tim 在文末开了个征集：「你见过最烂的提交消息是什么？」评论区已经有人投稿："stuff"（小写，无标点）、"asdfgh"（比 asdf 多滚了一圈）、"fix the thing"（哪个 thing？）、"."（对，就是一个句点，来自一个 2,000 star 的项目）。
你的仓库里，埋着多少这样的考古谜题？
热门跟贴