在版本控制系統中編寫更改消息的準則？

Question

是否有如何編寫的版本控制系統的changes message拇指任何規則或指導原則？

一個明顯的答案看起來似乎是a brief description of the most important changes，但實際上，選擇最重要的更改並簡要描述這些更改的相關方面並不總是很容易，特別是在開發的早期階段，添加大量代碼時。

Answer 1

這取決於項目的目標，我們使用Git和需要四個字段：

小結

相關機票（提交的一行主體）（用於與Trac的整合）

詳細報告

˚F uture工作所需

我們的Git倉庫有需要提交信息的形式正確，否則填寫的服務器拒絕提交掛鉤。

通過這種方式，人們可以看到摘要行，並獲得了什麼事是一個好主意，而詳細報告可用於任何棘手和今後的工作讓所有人看到什麼問題依然存在。

Answer 2

它並不總是容易選擇的最重要的變化，並描述這些變化

它可以是，如果你把你的提交緊，集中在一個特定的變化，如在相關方面「邏輯上分開的變更集」：請參閱「git commit frequency」。
（不要忘記wrap your comments properly：。這取決於其他處理工具（電子郵件，打補丁工具），註釋行的長度能夠決定的事情

Answer 3

我發現它有助於開始過去時態動詞提交信息：重構了X類，新增功能Ÿ，軋製回以前的變化等，這洽風格可以很容易通過閱讀消息當你稍後回顧他們時會記錄日誌。

它也是有用的在你的bug跟蹤系統添加到跟蹤ID的引用，這樣你就可以在必要時調查在未來的全背景的變化。