2010-05-10 82 views
5

我掙扎着問這個問題,但在這裏。 我使用源代碼控制,因爲多年來使用不同系統(svn,hg,git)的多個項目,並且我學會了如何通過遵循指導等來改進我的消息。 但是據我記憶,我從來沒有看過他們之後。提交消息的用途是什麼?

所以......你如何從自己的提交信息中獲益?當我需要回頭因爲我砸了一些東西而需要重新開始時,我通常會回到最新的「節點」(我開始或合併分支機構)。我是否只爲監控項目的人編寫這些消息,他們對發生了什麼事情感到好奇?

問候

回答

6

「送我的,你在過去兩週內做的事情的清單」 - 老闆

+0

我必須和老闆談談信任和程序員的工作方式。或者離開;) – ericteubert 2010-05-11 08:35:34

+3

這可能與信任無關。特別是在一個想到的案例中,他只想知道發佈說明文檔中應該寫些什麼。 – shoosh 2010-05-11 09:10:10

+0

好點shoosh – ericteubert 2010-05-11 11:49:09

3

有一件事我發現是,提交信息讓自己從一個好辦法沒有足夠的承諾。如果我不能把這些修改放到一個簡短的提交信息中,那麼我應該早一點提交修改。

4

你的消息比其他用戶多於你自己。儘管我確保即使在個人回購協議中也提交了良好的提交消息。有助於您在項目中受到偏離,並在該項目的幾個月內訪問,以便掌握最近在項目上完成的工作。

+2

沒有什麼比討厭更新並獲得幾十個更新文件而沒有消息告訴我爲什麼必須更改這些文件。 – tster 2010-05-10 21:55:22

+0

同意。我看到代碼提交給一個共同的圖書館,但卻不知道它們爲什麼被製作出來 - 我喜歡它);) – 2010-05-11 01:16:55

7

你把它們寫成對未來自我和團隊中其他人的幫助。給你一些當我發現他們有用的背景:

我曾經在一個項目中提交消息非常寶貴 - 我不止一次使用它們來追蹤那些年前的代碼。在該項目上,我們的錯誤跟蹤系統也與我們的VCS(ClearCase)集成在一起。因此,當您檢入更改時,它會在提交評論中記錄錯誤編號。這非常有用,可以讓您追溯到底發生了什麼變化以及原因。

所以總結一下,儘管如果你剛開始時(尤其是如果你是唯一一個在項目上工作的)提交消息可能看起來毫無意義,但是一旦你有一個成功的產品支持,它們就變得無價了由多個開發人員。

更新

提交信息的另一個有用的特徵是,它們需要你回顧和總結,你剛剛所做的更改。即使我記得我已經改變了什麼,在檢查文件之前我會經常對文件做一個快速區分。我會再次簡要地讀一遍,以確保沒有錯字,改變了我的意思等等。這是一種簡單的方法來檢查您的代碼,以找出那些會以其他方式進入代碼的小小錯誤。無論如何,在做完這些之後,我清楚地知道發生了什麼變化,因此我使用它在簽入文件時編寫了簡要的變更摘要。這是一個簡單的習慣,可以幫助您提高代碼質量,而您卻不費吹灰之力。

1

在最好的情況下,提交會綁定到功能/ bug跟蹤器中的工作項。這樣你就可以很容易地看到哪個功能/ bug已經被執行/修復。這不僅有助於瞭解某個修訂版是否包含功能或錯誤修復,還可以輕鬆創建發行說明。

1

沒有記錄的提交點會告訴你它是什麼?這就好比問'爲什麼書上有書名?',或者'爲什麼書有索引和頁碼?'。在我看來,沒有描述每個更改的源代碼控制日誌不會非常有用。

原因,您可能需要參考的提交信息包括

  • 的錯誤已經浮出水面,你想找到在代碼的那部分最後
  • 您決定撤消一些變化和需求變更以決定將哪個修訂版本還原爲

對於這些可能性中的任何一種,如果沒有好的提交消息,您將需要仔細查看每次提交的差異,直到找到代碼中的內容。