無規矩不成方圓，在涉及多人協作的項目中，對版本控制系統的提交使用適合於組織的規範，有助於簡化後期的管理維護。
人生苦短，規範提交
提交信息修改規範
每次提交，請寫明提交信息，並按規定書寫提交信息。規範化的提交信息除了便於查閱外，還容易被自動化工具處理。
一種參考的格式：
修改類型[(影響範圍)]: 標題
<--空行-->
[正文]
<--空行-->
[頁腳]
一般而言修改類型和標題是強制性的，影響範圍，正文，頁腳是可選的，但實際情況可以依據具體情形靈活確定。
修改類型（type）
修改類型是用於說明該 commit 的類型的，type 的參考類型如下，根據實際情況可以進行增減：
- feat: 新功能(feature)
- fix: 修復 bug
- docs: 只修改了文檔(documents)
- style: 代碼格式(不影響代碼運行的格式變動，注意不是指 CSS 的修改)
- refactor: 重構(既不是新增功能，也不是修改 bug 的代碼變動)
- test: 提交測試代碼(單元測試，集成測試等)
- chore: 構建或輔助工具的變動
- misc: 一些未歸類或不知道將它歸類到什麼方面的提交
影響範圍（scope）
影響範圍說明 commit 影響的範圍，比如數據層還是控制層，業務A還是業務B，又比如X目錄還是Y目錄等等，影響範圍的定義需要視具體場景與項目的不同靈活確定。
標題（subject）
標題是對於該 commit 目的的簡短描述，通常推薦結尾不加句號。
正文
正文是對標題的補充，非必須。正文應該包含更詳細的描述信息，如變更的動機，變更前後造成的一些重要影響等。
頁腳
頁腳處可以引用問題ID（ISSUEE_ID）, 工單名稱等相關資料信息。引用多個問題討論單或工單時,每行引用一份資料,分多行書寫。
一種參考的issue，工單引用格式：
- 問題討論單格式: issue#ID:問題討論 單名稱
- 工單格式:工單:工單名稱
提交主分支規範
根據實際情況，可以採用允許項目成員直接提交到主分支，或採用智能提交到其它分支，再合併到主分支的方式。
無論採用那種方式，主分支的代碼需要保證爲最終用於生產的代碼，臨時修改，測試，變更不完整，無法通過編譯的代碼不能直接提交（合併）到主分支，如有需要提交這類代碼可自行創建新分支提交，在代碼合併到主分支後再自行刪除相關分支。
如有需要可在主分支的基礎上按需打標（TAG），標識特定時候的主分支狀態。
文件編碼規範
除非有特別的原因，建議所有文本文件統一使用UTF-8編碼，提高不同平臺，環境下的兼容性。