Git管理規范
一、Git代碼倉庫創建規范
1.1 代碼倉庫創建規范
-
項目創建需符合
Group規范。 -
創建項目必須添加
Project description說明。 -
每個項目都需要
README.md文件。 -
除文檔說明類型倉庫，所有代碼倉庫都需要
.gitignore。
注：有模板的項目，要以統一的模板創建項目
1.2 Groups使用規范
Group 分為 rule(技術行為規范)、lab（技術預研）、common(基礎庫)、realicloud(基礎平台)、rexxox(產品)、customer(定制化開發項目)
1.3 目錄結構及權限介紹
- rule - Internal
-
- 主要用於存放技術行為規范相關資料
- lab - Internal
-
- 主要用於存放技術預研，比如shader預研、售前demo技術預研等。
- common - Internal
-
- 主要用於存放公共組件庫，基礎算法庫
- rexxxud - Private
-
- 主要用於存放底層基礎能力平台相關微服務，如PaaS層的接口、網關鑒權服務等。
- rexxxb - Private
-
- 主要存放產品相關業務代碼，如應用中心小程序等。
- customer - Private
-
- 主要存放客戶制定化開發項目代碼。
權限說明：gitlab主要包括三種權限Private、Internal、Public，分別為只對組內用戶開放、注冊用戶可見和公開，公司gitlab一般不使用Public
1.4 README文件規范
README文件結構如下：
<項目簡介/Introduction>
<快速使用/Quick start>
<文檔說明/Documentation>
Introduction用於闡述項目基本情況和功能（是什么，用來做什么的）Quick Start主要包括兩部分內容：簡易的安裝部署說明(Deployment)和使用案例(Example)。Documentation部分是核心的文檔，對於大型項目可以使用超鏈接代替
參考：
二、代碼提交規范（*）
2.1 commit三要素
提交規范一般包括：標題（類型、精簡總結）、內容、備注 。其中精簡總結 是必填的，類型 最好也填一下，其余都是選填。
2..2 標題
標題分為 類型 、 改動范圍 、 精簡總結 三部分：
2.2.1 類型
規范的主要類型如下：
- feat：新功能或功能變更相關
- fix：修復bug相關
- docs：改動了文檔，注釋相關
- style：修改了代碼格式化相關，如刪除空格、改變縮進、單雙引號切換、增刪分號等，並不會影響代碼邏輯
- refactor：重構代碼，代碼結構的調整相關（理論上不影響現有功能）
- perf：性能改動，性能、頁面等優化相關
- test：增加或更改測試用例，單元測試相關
- build： 影響編譯的更改相關，比如打包路徑更改、npm過程更改等
- ci：持續集成方面的更改。現在有些build系統喜歡把ci功能使用yml描述。如有這種更改，建議使用ci
- chore：其它改動相關，比如文件的刪除、構建流程修改、依賴庫工具更新增加等
- revert：回滾版本相關
其實實際開發中最常用的就是 feat、fix 和 perf，git提交基本上都是實現需求，更改bug，性能優化。除了上述這些主要類型，我們也可以根據團隊要求定制類型，畢竟規范是死的，人是活的嘛。比如為了大家更易讀，我們只留幾個常用的，並且全改成中文，如：
- 功能更改：新功能或功能變更相關
- 修復bug：修復bug相關
- 優化：性能改動，性能、頁面等優化相關
沒有好與不好之分，適合團隊的就是最好的！
2.2.2 改動范圍
當項目划分為好幾個模塊的時候，指定改動的模塊是很有必要的事情，這樣在git提交記錄中，很容易看出提交者更改的是哪個模塊。比如本次修改了compiler（編譯器）模塊，下次修改了 router（路由）模塊，一目了然。如：
- compiler
- router
2.2.3 精簡總結
必填的精簡總結是非常重要的，一般是是總結概括的文字。要讓人一眼就能看出來主要提交了什么，是添加了功能還是解決了問題，同時它也是大多數git管理工具默認展示的一行。如果你寫的標准，那么提交記錄看起來就很漂亮很規整。例如：
fix: 修復了無限抽獎的bug
2.3 內容
內容主要填寫詳細的改動內容，可換行。當然，不必像寫一篇小作文似的長篇大論，畢竟我們程序員的時間還是很寶貴的。如果精簡總結寫的比較完美，內容不寫也是沒關系的。不過如果更改確實很多，並且時間充裕的話，把本次提交內容的實現、需求以及背景都填寫，是很負責的做法。比如：
fix: 修復了無限抽獎的bug
在網絡不好時，多次抽獎的接口可以被重復調用。
此次更改了抽獎接口的邏輯判定，在並發請求中……采用了……所以……。
2.4 備注
備注看起來並不是那么重要，主要作用就是有一些額外的hook補充，比如提交記錄之后，自動觸發代碼聯動編譯，或者自動生成git提交的通知。
三、倉庫代碼規范（*）
