我很好奇什麼樣的內容應該在一個版本化的文件提交評論。它是否應該描述通常發生了什麼變化（例如「小部件屏幕已更改爲僅顯示活動小部件」）還是應該更具體一些（例如，「將新條件添加到fetchWidget查詢的where子句以僅缺省檢索活動小部件「）SVN/Versioned文件提交註釋包含哪些信息？
單個提交應該是多少原子？只是在單個提交中包含更新後的查詢的文件（例如，「更新小部件屏幕以僅默認顯示活動小部件」），還是應該和其他一些更改+界面對屏幕的更改共享同一個提交像（「更新窗口小部件屏幕：A）默認情況下顯示活動窗口小部件B）添加按鈕切換顯示非活動窗口小部件」）
我看到顛覆提交評論使用得非常不同，並想知道其他人的成功與否。一些評論與「更新文件」一樣簡短，而另一些評論則是很長的段落，而其他評論則以可被查詢並與諸如JIRA之類的外部系統相關聯的方式進行格式化。
我曾經對改變的原因以及具體的技術變化做了極爲詳盡的描述。最近我一直縮減，只是給一般「這是我在這個頁面上改變了什麼」的評論。
一些準則：
就我個人而言，我嘗試對我更改和/或添加的內容做一個簡短的總結。有些東西會提醒我，「哦，是的，這可能是我在這個商業對象中添加額外規則的地方。」因爲我總是可以運行「差異」來查看具體發生了什麼變化。
它應該簡要解釋提交包含的內容。這應該包括錯誤修復或增強的票號。我聽過的關於撰寫評論的最好建議是「這樣的代碼，好像下一個維護你的代碼的人是一個知道你住在哪裏的殺人瘋子」。這同樣適用於提交評論。
有一件事情可以幫助我思考寫什麼或不寫什麼，最終應該可以從提交註釋中編譯內部技術發行說明。
我也覺得它非常有用，建立標籤提交的意見，像#doc，#typo，#refactor，...
提交時，我也不會太描述 - 這樣做的原因這種或那種方式應該在文檔中，或者在代碼註釋IMO中。
有用的提交註釋是那些添加有用的信息，這些信息不易從更改中自行提取。縱觀差異列表會顯示什麼改變，所以提交評論應集中在解釋爲什麼進行了更改：
修正了由於空指針引用（錯誤號234）。
增加了與服務器斷開連接的命令（功能請求22）。
清理未來更改的代碼。
評論的另一個有用的排序是一個總結出更大的更改集的總體目標：
如果您使用錯誤跟蹤系統，最好包括您正在使用的適用於此更改的錯誤/增強功能。無論如何，您很多時候都會重新編寫錯誤描述中的內容。
它應該包含一個小小的更改摘要（允許在更改列表中進行篩選）以及爲什麼應用更改。
新代碼的文檔屬於源代碼本身;不在日誌消息中。 （並且應該刪除應用於舊代碼的只有的註釋，您可以隨時通過SCC系統的歷史記錄查看那些舊註釋）。