提交代碼時多久進行一次評論？

Question

什麼是COMMENTING提交的最佳實踐？

有點背景。

• 我們所有的項目都使用版本控制（顛覆/ SVN/GIT），
• 他們中的大多數是由2個或更多的開發者感動，
• 我們使用Springloops來承載我們的版本控制，因爲它「只是作品「，並且比擁有一個內部開發人員維持它更小，
• 因爲我們的許多客戶有特殊的設置，並且因爲它爲多個用戶設置這些環境，所以我們很少打擾到本地開發環境。大多數客戶在雲中有一個開發地點，然後是一個現場位置。 Springloops被配置爲自動將每次提交推送到開發服務器，並且開發人員必須手動推送到實時位置。

我們的政策一直是評論你犯下的一切，但我們幾個最近背叛反對這一想法。

評論一切的問題有兩個方面，它的工作量更大，而且用處不大。以下是我們所看到的問題：

1. 它鼓勵人們做出涵蓋的東西，已經在版本控制（即我改線42做等等）的意見。你可以比較以獲得相同的信息！

2. 或者它會填滿你的評論流與無用的評論，這是一個巨大的痛苦，如果你想要通過評論搜索。

   • 保證金的問題與IE8
   • 另一個修復保證金在IE8
   • 還原，去年修復，並試圖在IE8

無論是用保證金別的東西這些東西只是增加了很多時間，並沒有增加任何價值。評論只有在它們足夠具體且稀缺到可以掃描一切時纔有用。

我們被告知Git比Subversion更聰明地處理這個問題，我們願意改變，顯然有一個本地開發環境，並且只提交批量的更改也會有所幫助，但基於我們的用例這可能是效率方面的淨虧損。

我很想聽聽人們評論提交的最佳實踐，感謝任何反饋！

Answer 1

我的哲學是：

1. 儘快
2. 更新提交併建立之前提交
3. DIFF之前提交
4. 不破BUILD：更新提交後測試構建

所有這些都是每個團隊成員都要遵守的個人紀律問題。如果構建管理器破壞構建，則「鼓勵」構建管理器在午夜將其喚醒。

Answer 2

所有簽到應該有一個評論，但它不應該改變自己。評論應該是一個關於改變的簡短的一般性評論，而不是改變的實施細節，正如你所說，它可以在改變本身中找到。

Answer 3

我的經驗法則是，如果我不能用不到兩個句子來總結提交的更改，那麼自上次提交以來，它已經太長了。

至於在該句子中寫什麼，我從來不會說任何行特定或文件特定的，因爲該信息嵌入在提交中。我通常會提到簡單英語中的具體變化，就像我將其解釋給不屬於該項目的人員那樣。

這很好，因爲無論是我還是其他人幾個月後，他們都可以像提交項目開發過程一樣閱讀提交日誌。我甚至做了只是我的提交日誌的複製和粘貼的博客文章。

Answer 4

Git不會爲你解決問題;你需要回答這個「簡單」問題：你如何增加評論的價值？

一些準則：

1. 不要提在評論什麼是顯而易見的承諾本身（如該行已更改）。現代工具將在屏幕上顯示提交消息和並行提交。沒有必要重複工作。
2. 相反，請解釋您爲什麼進行更改 - 通常不明顯。這是一個錯誤報告？包含錯誤的ID。這是你找到的東西嗎？

3. 如果您發現自己經常處於必須在一次提交中提交多個修復程序的情況，那麼您需要學會專注。當你改變代碼時，不要隨心所欲。做一件事，完成它，承諾它。然後做下一件事。

   如果您在途中偶然發現某些東西，請留言（在紙上或在一個額外的文本編輯器中，您不停地在屏幕的某個角落盤旋）。 不要總是打斷你的工作！多任務/遞歸代碼編輯對質量和壓力水平有嚴重影響。

你仍然會得到很長的「固定IE8保證金」提交列表，但這本身並不是問題。當你說「我們想要搜索評論」時，你必須想出一種方法來將有用的信息放入評論中，以便對其進行合理的搜索。例如，對於缺陷ID總是使用相同的格式。純文本不適合搜索，特別是提交應該簡潔的消息。

只是忽略評論不是一種解決方案，它可能是懶惰或是作爲反社會人士的標誌（「誰在乎別人是否有問題？」）還是壞的訓練（「我不知道該寫什麼「）。

第一次和最後一次都可以通過訓練來解決。第二個通過擺脫風險（即解僱這個人）。

世界上沒有版本控制工具可以幫助您。