Git團隊開發管理規範、GitFlow開發規範
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提交的通知。