關於評論代碼有很多討論，但評論簽到怎麼樣？版本控制評論的最佳做法
我發現這個博客帖子： http://redbitbluebit.com/subversion-check-in-comment-great-practices/
至於是誰發佈說明放在一起的傢伙，我正在尋找辦法，使這項工作更容易。
目前我們爲<Begin_Doc>...<End_Doc>定義了我們自己的方案，用於任何應該發佈給我們軟件客戶的方案。但即使是內部的東西，我也想知道每個變化的「原因」。
每個功能都有一張票/發行/錯誤報告/任務/無論你打電話給它，並且票號始終在檢入註釋中引用。這給出了上下文。
我會主張不要使用/重載你的版本控制系統。我建議問題跟蹤軟件更好。
首先，開發人員在已經存在於需求文檔或問題/缺陷系統中的提交消息中添加所有上下文和重複信息似乎不太合適。
您可以使用一個工具來收集提交註釋中的相關修復/問題編號，然後從您的其他存儲庫收集這些修復/問題編號，但我認爲基本上使您的修訂工具成爲面向外部的東西是個錯誤。
您需要定義Source/version repository/SVN是什麼 - 它是用於管理源文件，還是用於編寫發行說明。我認爲它不應該超載。
關鍵是你打算怎麼處理評論。如果您正在創建發行說明，那麼您可以按照您的建議進行操作。不過，我會建議您在其他位置跟蹤發行說明，例如在項目管理或錯誤跟蹤工具中。
至於與開發人員相關的評論，我們通常會要求人們解釋他們在做什麼，一個句子的解釋。它不需要太過正式，主要是因爲如果是人們會反對它。另外，如果您知道是誰做的，並且您有快速評論，則通常可以追溯該問題並找到該人。
同樣，如果您使用的工具如FogBugz，您可以將SVN簽入鏈接到案例編號。這意味着您可以查看案例以獲得完整的討論，評論，截圖等。這些信息比您在簽入評論中輸入的信息多得多。
我會說要嘗試遵循changelog風格。第一行應該是一個簡短的摘要，幷包括問題/票號（如果有的話）。根據VCS處理多行提交消息的方式，這可能會有一個空白行，然後是更完整的多行描述。我認爲強加任何嚴格的格式是不合理的，因爲它會阻止頻繁的提交，但只要重要提交（那些關閉問題或重大更改）以這種方式完成，就應該沒問題。
如果您使用Trac或roundup + svn集成之類的東西，它可以從提交消息中挑選問題編號。因爲它們非常有用，我總是會把它們放在第一行。
同意紀念，但你也應該寫一點關於你爲什麼執行修改/錯誤修復你的方式。 如果您經常在檢查中相信，您還應該包括TO DO，以便您的一位同事完成任務。
編輯：鑑於這是我迄今爲止最低調的答案，我認爲值得強調最後一段隱藏的內容：我是獨資經營者。我對這些項目擁有100％的所有權，不與其他開發人員合作。在一家擁有多名開發人員的店鋪中，我在這個答案中所說的一切可能完全不合格。
我在這裏訂閱DRY在所有的東西。
我幾乎從不給我的提交添加評論。評論幾乎總是重複自己。 「這個提交中改變了什麼」這個問題的答案？幾乎總是在差異。
當我在查看一個文件並詢問「這裏發生了什麼？」時，我所做的第一件事就是查看以前版本的差異。 90％的答案立刻顯現出來，不是因爲代碼不言而喻，就是因爲我在代碼中有一些不言自明的東西。如果不是，我將文件的修改日期與錯誤跟蹤系統關聯起來，答案就在那裏。
這總是有效的。有時需要進行一些調查才能找出問題，因爲我沒有充分評論我的代碼。但我從來都不能很快找到答案。
我唯一一次給提交日誌添加註釋的時候，我知道差異不會幫助我。例如，當我對一個班級的成員進行排序時：在這種情況下差異會告訴我的唯一事情就是發生了一件非常重要的事情。當我這樣做時，我會在修復文件後立即提交該文件。沒有適當的地方來評論文件中該範圍的更改，因此我添加了一條評論，說明此修訂版中的唯一更改是對成員進行重新排序。你可能會問：「爲什麼你不會在文件頂部修改歷史記錄中發表類似的修改？」我沒有在我的文件頂部保留修訂歷史記錄，這是一個可怕的，打破一生的習慣改變，我從來沒有後悔過，修訂歷史是Subversion。）
如果我沒有100％的所有權項目，可能會有所不同。將錯誤修復與提交相關聯可能太難了。培訓其他開發人員編寫可以有效依賴版本控制的風格可能太難了。我不得不看。
如果在你發佈這兩年後你的立場發生了改變，我會很好奇。 – 2011-06-23 14:16:45
我推薦功能評論。評論應該提供改變的摘要。如果有什麼改變，爲什麼。每個提交都應該是可以解釋的，如果你不能清楚地解釋它，你可能不應該檢查它。
使用源代碼控制日誌時要記住的最重要的事情是他們在那裏確定何時和什麼是改變。功能越多，越詳細越好。承諾應在一口大小的片斷，這可以解釋一口大小的評論。
我個人的偏好是這樣的風格：
更新錯誤日誌記錄系統。
使我改變小幫助：我可以提供我的變化詳細描述這種方式。
的簽入註釋應該是一個開發者想要的信息：這包括重構，代碼背後的動機等
我們儘量保持簡單：寫一個句子描述了你所提交的變化。如果開發人員需要兩個或更多的句子來描述提交，那麼提交可能是兩個不相關的工作。當這樣的提交最終在版本控制中時，很難單獨恢復修復。
我們希望在我們的提交評論中包含的另一條信息是提交修復/實現的缺陷/功能號。並非我們所做的所有工作都與我們問題跟蹤系統中的缺陷有關，因此這不是強制性的。
我們在我們提交的評論中提供的最後一條信息是名稱的一個代碼評論者。這是在提交之前對變更進行完整性檢查的人員。
在我們的項目中，我們一貫主張提供一些細節什麼提交即將在不必重複就像我們使用Trac的，並有我們的資源庫整合問題的相關信息，以幫助。其優點是，您可以在評論中引用問題單，並僅說明所執行的解決方案或步驟。然後，Trac自動將參考號碼鏈接到原始問題編號，並將您的提交信息用作問題的評論。然後當你想看看已經做了什麼時，你可以簡單地閱讀Trac中的問題，並有完整的上下文。
至於發佈說明我們已經發現，服用一個版本中的問題列表，並使用提交作爲意見的基礎信息一直很好。通常情況下，您的發行說明中不會包含原始提交消息，因爲您的客戶並不真正在意每一個細微的變化，甚至可能包含在評論中的詳細程度。所以您通常需要進行大量的編輯來突出顯示在該版本中實施的主要更改和錯誤修復。
讓您的工作環境，讓你可以從售票入住註釋直接進入。一種典型的方法是使票號可點擊。 – 2011-12-01 09:34:30