什麼構成有效的SCM消息？

Question

我目前正在爲一個新的SVN實例編寫一些鉤子，我想就人們認爲應該應用什麼標準來驗證提交消息是否足夠提供一些反饋。廣泛的開發人員將使用這個特定的SVN實例，並對SCM最佳實踐有不同的瞭解。

我試圖在強制足夠的信息恰當地描述變化但不會變得過於熱情，並且讓那些擁有簡潔而完美有效的信息的人們生活困難之間取得很好的平衡。我試圖拒絕的是類似於「更新」或「添加文件」的消息，因此對字數和消息長度的限制是明顯的選擇。

您還會使用其他哪些標準拒絕未正確描述更改的郵件？請保持回覆集中在你如何符合令人滿意的信息;我非常清楚社會對教育的需求，這種情況正在發生。

順便說一句，不需要擔心在這種情況下引用工作項或錯誤。

Answer 1

我誠實地認爲任何具體的標準作爲一個硬性要求都是毫無價值的。如果你曾經看過一個網站需要最少數量的評論/評論中的字符（dealextreme，甚至想到這個網站），你很快就會意識到效果並不是你想要的。與保證評論和評論時間更長的人相比，他們只會發現更多填充符，以確保它們達到已知和硬編碼的最小值。

最終，問題必須作爲社會問題而不是技術問題來處理。每一個不恰當的非信息評論都需要引起人們的注意，並向他們解釋。

這仍然不會解決問題100％，但它是我找到的最接近的工作方式。

說了這麼多話，如果有人能夠用不少於40個字符寫出一致的優秀CVS評論，我會非常驚訝。 :)

Answer 2

這可能不會讓你多。如果你拒絕「更新」，那麼人們會做出一些讓他們承諾的事情。「saldkj dot quux增加了一個新的fizzleglorb。」社會問題的技術解決方案不起作用。

另外，也許可以考慮像Git這樣的工具，以便您可以合併相關的提交。當您處於黑客行爲的中間時，您不想撰寫詳細的消息。但是當你要回顧你的工作並將其壓縮成一個邏輯塊時，那就是當你想添加關於你正在做什麼的文檔的時候。

Answer 3

我同意其他答案。不願意合作的人總會找到解決方案的辦法。

不過，我一直做的是以下幾點：

• 設置一個pre-commit鉤子來檢查註釋提供（即提交信息不爲空），只是爲了防止人（我自己包括）'意外'忘記提供一個。儘管不要擔心對提交消息的內容進行任何檢查;這是浪費時間。
• 放的pre-revprop-change鉤子到位，允許編輯後提交信息（這是默認不允許的）

Answer 4

我與其他的答案一致認爲，在這一點上驗證不會是100％有效。但有一些驗證將有助於實現部分合規。

因此，我建議如下：

• 有個性需求的最小數量。根據收集的調查確定合適的人數。
• 列出一些可能的不可接受的關鍵短語。注意不要包含既可以接受也可以不可接受的詞語，如「更新」。
• 強調級聯SVN提交策略時的規則。
  確定一個非常好的介質來定位用戶。

我相信規則會盡量減少不符合規定的用戶的出現，但不能完全消除它們。

希望這會有所幫助。

Answer 5

我發現至少需要15個字符（不包括空格）能很好地工作。不要試圖用更復雜的檢查來過度使用它。設置提交郵件列表也有幫助;它宣傳了很好的例子並增加了社會控制。

總是會有一些開發人員將其作爲一項挑戰，以儘量減少提交消息中的任何有用信息。但是如果我在查看SVN日誌之前（90％爲空）和之後（80％有點用處）預安裝鉤子，我認爲這裏情況已經有所改善。