協同開發中SVN使用規范試用
目標，要求
本次svn提交規范主要針對當前項目中出現的svn管理難，開發流程控制難掌控，項目進度記錄不准確等問題而提出。要求每個角色都要進行規范化svn作業。
目錄結構與開發模式
分散式分支開發模式原理
Svn://project/
+trunk/（主開發目錄）
+branches/（分支開發目錄）
+dev_1.0_function1（功能性分支1）
+dev_2.0_function2（功能性分支2）
…
+tags（存檔目錄，不允許修改）
a) 1.0的開發，做一個dev_1.0的功能性分支
Svn://project/
+trunk/（不承擔開發任務）
+branches/
+dev_1.0_function1
+tags
b) 1.0功能開發完成，合並分支到主干
Svn://project/
+trunk/（merge from branch dev_1.0_function1）
+branches/
+dev_1.0_function1（開發任務結束，凍結）
+tags
c) 測試完成，根據主干做一次1.0的tag
Svn://project/
+trunk/（merge from branch dev_1.0_function1）
+branches/
+dev_1.0_function1（開發任務結束，凍結）
+tags
+tag_release_1.0（copy from trunk）
d) 1.0版本結束，做下一個版本的開發2.0
Svn://project/
+trunk/（merge from branch dev_1.0_function1）
+branches/
+dev_1.0_function1（開發任務結束，凍結）
+dev_2.0_function2（2.0的開發）
+tags
+tag_release_1.0（copy from trunk）
e) 1.0版本出現bug，直接在dev_1.0版本上修復
Svn://project/
+trunk/（merge from branch dev_1.0_function1）
+branches/
+dev_1.0_function1（bugfix）
+dev_2.0_function2（2.0的開發）
+tags
+tag_release_1.0（copy from trunk）
f) 選擇性的進行代碼合並
使用規范
命名規范
分支名稱采用固定名稱與下划線結合方式進行功能性分支描述如:dev_1.0_crm。
存檔名稱統一采用tag_release_版本的方式。
提交規范
一、 提交之前先更新
在每次提交文件的時候，先進行必要的更新操作，因為，有可能在你修改文件的期間，別人也修改了同樣的文件，那么本次的提交很可能會失敗。
二、 保持原子性的提交
每次提交的時間盡可能的短，如當你修改了UI界面，完成了功能小細節，確認了bug完善就提交代碼。
三、 不要提交本地配置文件，自動生成的文件，自己不明白的文件
本地環境因人而異，因此就有了不同的配置文件，緩存生成文件等，在提交的時候，盡可能檢查提交的內容是否是包含了類似不必要的文件。
注釋規范
每次提交必須書寫明晰的標注
在項目中，如果沒有注釋，會導致管理人員不能清晰的把握每次的項目提交的概要，bug管理與文件不對稱，難以掌控項目的進展等問題，因此建議填寫注釋，同時不能填寫一些無效，無用的信息。填寫好的注釋應該是能概要的描述所提交的文件的基本功能的信息，也建議使用下面的規范。
注釋規范寫法，提交前加注釋標簽
- Todo： 任務清單
對於需求性的功能使用todo前綴標簽，如加入經紀公司模塊，使用類似以下語句：Todo： 增加經紀公司模塊
- Bugfix:： bug修復
對於系統bug,等信息提交前加上bugfix標簽，如修復待遇顯示不正確：Bugfix: 修復期望工資待遇顯示錯誤bug
- Junk: 零碎碎片
其他的一些無效的信息修改，如靜態資源的壓縮：Junk： css，js文件壓縮
效果圖：
