GitHub 10萬條提交記錄扎心真相

10,000條提交記錄里，2,300條在集體裝死。

開發(fā)者 Tim 跑了個腳本，扒了50個開源倉庫的提交歷史。結果像一盆冷水——近四分之一的消息，讀完和沒讀一個樣。你盯著"fix""update""wip"這種單字謎語，仿佛在考古現場挖到一張空白紙條。更魔幻的是，有人干脆敲個"."就提交了，像在給代碼庫打摩斯電碼。

Tim 的統(tǒng)計清單堪稱行為藝術：fix、update、wip、.、changes、stuff、misc、asdf。最后那個"asdf"大概是鍵盤上隨手滾了一圈。這些不是惡作劇，是真實存在于生產環(huán)境的提交記錄。當你凌晨三點被叫起來排查線上故障，翻到這條"fix bug"，想順著網線過去問問具體修了哪個 bug——卻發(fā)現作者三年前已離職。

「努力過」的失敗更氣人

有些提交消息試圖認真，但認真錯了方向。"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）的格式，類型標簽+具體描述+業(yè)務場景，三秒內你能判斷這條改動會不會踩到你的坑。

Tim 的樣本里，采用約定式提交的倉庫，優(yōu)質消息率達到82%；沒采用的，54%。這28個百分點的差距，不是代碼能力問題，是協(xié)作意識的代差。

一個 Python 腳本的「審判」

Tim 沒停留在吐槽。他寫了個開源工具 git-commit-analyzer，給提交消息自動打分。

核心邏輯粗暴有效：定義一組"廢話詞庫"（fix、update、change、wip、stuff、misc），檢測消息長度和關鍵詞。少于兩個詞且命中詞庫？判為 vague（模糊）。空消息？直接 bad（不合格）。其余算 good（可用）。

腳本跑完輸出一個百分比得分。Tim 建議把這個塞進 CI/CD 流水線——提交質量低于70%就阻斷構建，從流程上逼團隊長記性。配置只有幾行 YAML，但殺傷力堪比代碼審查。

這個設計戳中了一個老問題：技術團隊的壞習慣，靠自覺改不了，得靠工具「羞辱」。就像單元測試覆蓋率，你不量，它就永遠「差不多行了」。

為什么程序員寧愿寫「asdf」？

Tim 的數據沒解釋動機，但場景不難還原。趕 deadline 時，提交框像驗證碼一樣礙事；個人項目里，「反正只有我看」；團隊沒規(guī)范，劣幣驅逐良幣，你寫詳細描述反而顯得格格不入。

更隱蔽的原因是：寫好的提交消息需要上下文切換。你剛調完一個棘手的 race condition，大腦還在內存狀態(tài)里，手指已經本能地敲了"fix"。等你想補一句清楚的描述，Git 的默認編輯器可能還是 Vim，退出都要查教程。

約定式提交的價值在這里顯現——它降低了「寫好」的認知負荷。feat/fix/refactor/docs/test 六個前綴，像麥當勞的點餐編號，不用動腦子就能分類。剩下的精力專注描述 WHAT 和 WHY，而不是糾結格式。

Tim 的工具還做了時間模式分析。有些團隊的提交質量隨 sprint 周期波動，deadline 前一周斷崖式下跌。這種數據比任何復盤會都誠實。

開源倉庫的提交歷史是技術債的化石層。Tim 扒的50個倉庫里，有些早期代碼像考古遺址，層疊著"wip""fix again""final fix""really final fix"的地層。后來引入約定式提交的團隊，地層突然變得可讀，像從亂葬崗切到了公墓區(qū)——至少每個坑位有墓碑。

這個對比讓 Tim 的興奮感有據可依。82% vs 54%不是抽象數字，是后人排查問題時少花的幾百個小時，是 onboarding 新成員時少翻的幾千條記錄。

Tim 在文末開了個征集：「你見過最爛的提交消息是什么？」評論區(qū)已經有人投稿："stuff"（小寫，無標點）、"asdfgh"（比 asdf 多滾了一圈）、"fix the thing"（哪個 thing？）、"."（對，就是一個句點，來自一個 2,000 star 的項目）。

你的倉庫里，埋著多少這樣的考古謎題？