最近釋出的 Cocommit，一款旨在使用 AI 增強 Git 提交資訊的工具，在開發者中引發了關於編寫提交資訊的基本目的和最佳實踐的激烈討論。雖然一些人認為 AI 輔助是對工作流程的有價值的增強，但其他人質疑自動化工具是否能解決有效版本控制文件的實際挑戰。
提交資訊的目的使開發者產生分歧
爭論的核心是一個基本問題：什麼是好的提交資訊？討論中的許多開發者強調，提交資訊應該回答未來開發者（包括未來的自己）在審查程式碼歷史時會問的關鍵為什麼問題。這一觀點與 Cocommit 提高提交質量的既定目標一致，但社群成員對 AI 工具是否能真正捕捉到程式碼更改背後的上下文推理表示懷疑。
「我不明白為什麼開發者很難花30秒時間來回答這個問題：為什麼這個提交存在？這是當你在
git blame中找到提交時會問的問題，所以直接回答它就好了。」
一些開發者認為，依賴 AI 生成提交資訊可能是一個危險訊號，表明開發者可能並不完全理解他們所做的更改。其他人則認為，diff 已經顯示了什麼發生了變化，使得冗長的描述變得多餘，而提交資訊應該專注於從程式碼更改本身不明顯的高層次上下文。
開發者討論的要點
- 提交資訊的目的：應該解釋為什麼做出更改，而不僅僅是更改了什麼
- 流行的提交資訊方法：
- Conventional Commits 格式（
feat:、fix:等） - Git trailers 用於元資料
- Kernel 補丁描述
- Gitmoji（使用表情符號指示更改型別）
- Conventional Commits 格式（
- 建議的提交資訊框架：
- "應用後，此提交將..."作為思考提示
- 回答"為什麼這個提交存在？"
- 對 AI 生成資訊的擔憂：
- 可能無法捕捉專案特定的上下文
- 可能使不理解自己更改的開發者得以矇混過關
- 可能產生冗長但沒有價值的資訊
提交格式的標準化與靈活性
討論揭示了關於提交資訊格式標準的不同偏好。一些開發者提倡遵循已建立的約定，如 Conventional Commits，它使用 feat: 和 fix: 等字首來分類更改。其他人則反對這種嚴格的結構，建議 Git trailers 可能是一種更靈活的替代方案，不會佔用簡訊息中的寶貴空間。
有趣的是，幾位開發者一致認為，擁有某種標準——即使是他們個人不喜歡的——也比沒有標準好。這種觀點表明，像 Cocommit 這樣的工具可能在幫助團隊保持提交資訊的一致性方面有一席之地，即使具體格式在不同專案間有所不同。
AI 作為助手 vs AI 作為替代品
一個關鍵區別出現在使用 AI 審查和增強人工編寫的提交資訊（Cocommit 似乎就是為此設計的）與完全將提交資訊的編寫外包給 AI 之間。許多開發者對前者表示開放，同時強烈反對後者。
一些評論建議了 AI 在提交資訊中的替代用例，例如用合成的猜測來裝飾缺乏適當提交資訊的倉庫，或幫助大型團隊標準化資訊。這些觀點表明，開發者可能更願意接受增強現有工作流程而非完全替代人類判斷的 AI 工具。
簡潔 vs 詳細：尋找適當平衡
提交資訊的適當長度和詳細程度成為另一個有爭議的點。一些開發者認為只需幾個詞就足夠了，而其他人則堅持認為非顯而易見的更改需要更全面的解釋。這場辯論突顯了像 Cocommit 這樣的 AI 工具在確定不同型別更改的適當詳細程度方面面臨的挑戰。
幾位開發者建議採用平衡的方法，讓程式碼註釋解釋實現細節，而提交資訊則專注於更改的理由。這種什麼和為什麼之間的區別似乎是許多經驗豐富的開發者遵循的指導原則，無論他們對資訊長度或格式的立場如何。
總之，雖然像 Cocommit 這樣的工具為維護一致、資訊豐富的提交歷史提供了潛在好處，但開發者社群對 AI 輔助是否能解決編寫好的提交資訊的核心挑戰仍存在分歧。最有價值的提交資訊似乎是那些能清晰傳達意圖和上下文的資訊——這需要對程式碼和更廣泛的專案目標的人類理解。AI 是否能有效增強這一過程而不降低其價值，仍是一個開放性問題，隨著這些工具的成熟，這一問題可能會繼續發展。