SVN送出更新的一個準則

查閱了一下網絡和部落格園，發現還沒有一個明确地指導源碼管理送出準則的相關文章，是以鬥膽整理了一部分自己平時開發管理的心得，加上查閱了部分英文資料寫了一個不算很完善的SVN送出準則。

負責而謹慎地送出自己的代碼

SVN更新的原則是要随時更新，随時送出。當完成了一個小功能，能夠通過編譯并且并且自己測試之後，謹慎地送出。

如果送出過程中産生了沖突，則需要同之前的開發人員聯系，兩個人一起協商解決沖突，解決沖突之後，需要兩人一起測試保證解決沖突之後，程式不會影響其他功能。

如果送出過程中産生了更新，則也是需要重新編譯并且完成自己的一些必要測試，再進行送出。

保持原子性的送出

每次送出的間歇盡可能地短，以一個小時，兩個小時的開發工作為宜。如在更改UI界面的時候，可以每完成一個UI界面的修改或者設計，就送出一次。在開發功能子產品的時候，可以每完成一個小細節功能的測試，就送出一次，在修改bug的時候，每修改掉一個bug并且确認修改了這個bug，也就送出一次。我們提倡多送出，也就能多為代碼添加上保險。

不要送出自動生成的檔案

Visual Studio在生成過程中會産生很多自動檔案，如.suo等配置檔案，Debug,Release,Obj等編譯檔案，以及其他的一些自動生成，同編譯代碼無關的檔案，這些檔案在送出的時候不應該簽入，如果不小心簽入了，需要使用Delete指令從倉庫中删除。

不要送出不能通過編譯的代碼

代碼在送出之前，首先要确認自己能夠在本地編譯。如果在代碼中使用了第三方類庫，要考慮到項目組成員中有些成員可能沒有安裝相應的第三方類庫或者沒有放入GAC（針對.Net Framework）中，項目經理在準備項目工作區域的時候，需要考慮到這樣的情況，確定開發小組成員在簽出代碼之後能夠在統一的環境中進行編譯。

不要送出自己不明白的代碼

代碼在送出入SVN之後，你的代碼将被項目成員所分享。如果送出了你不明白的代碼，你看不懂，别人也看不懂，如果在以後出現了問題将會成為項目品質的隐患。是以在引入任何第三方代碼之前，確定你對這個代碼有一個很清晰的了解。

提前宣布自己的工作計劃

在自己準備開始進行某項功能的修改之前，先給工作小組的成員談談自己的修改計劃，讓大家都能了解你的思想，了解你即将對軟體作出的修改，這樣能盡可能的減少在開發過程中可能出現的沖突，提高開發效率。同時你也能夠在和成員的交流中發現自己之前設計的不足，完善你的設計。

對送出的資訊采用明晰的标注

+) 表示增加了功能

*) 表示對某些功能進行了更改

-) 表示删除了檔案，或者對某些功能進行了裁剪，删除，屏蔽。

b) 表示修正了具體的某個bug

<a></a>

你在這裡說明了SVN送出的一些準則，挺好的。但不完整，SVN送出中最重要的一部分，你遺漏了，就是SVN comment的事情，以及相關的一些準則。

SVN comment規則

[CODE]開頭，表示：編碼

[BUG]開頭，表示：修複BUG

[PM][DOC]開頭，表示項目管理文檔

等等，你可以定義自己的規則

總結的挺好。以前給新員工教育訓練的時候講過這個話題，不過沒想過要發到網上來，還是你有心。

我總結起來，就是要原子性，獨立性，寫日志。

就是每次修改肯定有個目的，每次送出的代碼應該能完整的達到這個目的，不能把一次修改分成多次送出。這是原子性。在svn裡展現為一個變更集。

如果改動比較多，可以分解為解決問題的若幹個步驟，那麼分批次送出，盡量每個變更集都是目的明确的，不要帶有一石多鳥的效果。這是獨立性。

做到這兩點，日志就很好寫，然後把日志寫明白。做不到這兩點的話，寫日志可羅嗦了。

機器生成的代碼原則上不送出，但是如果是類庫工程，不妨把有裡程碑意義的版本的二進制成品在svn裡留一份。

關于多久送出一次，我覺得這個就太教條了，有時是幾分鐘送出一次，有時是幾小時送出一次。我覺得不必要求每天下班時要送出。但是上班時要檢視更新是必要的。

關于日志，作為一個團隊，盡量要用術語和符号，這樣可以使日志簡潔。