Gitlab Flow
項目的分支狀態(tài)為：
master：主分支簸呈，用于存放對外發(fā)布的版本榕订，任何時候在這個分支拿到的，都是穩(wěn)定的分布版蜕便；
develop：開發(fā)分支劫恒，用于日常開發(fā)，存放最新的開發(fā)版轿腺；
feat-xxx <feature branch>：功能分支两嘴，一旦完成開發(fā)，它們就會被合并進develop或master吃溅，然后被刪除溶诞；
hotfix-xxx<hotfix branch>：正式環(huán)境補丁分支，一旦完成開發(fā)决侈，它們就會被合并進develop或master螺垢，然后被刪除；
fix-xxx<fix branch>：開發(fā)環(huán)境補丁分支赖歌，一旦完成開發(fā)枉圃，它們就會被合并進develop或master，然后被刪除庐冯；
分支詳解
master 主分支
代碼庫有且僅有一個主分支孽亲。提供給用戶使用的正式版本，都在這個主分支上發(fā)布展父。每次發(fā)布打上Tag標簽返劲，如：0.1，0.2 或 0.3栖茉。
develop 開發(fā)分支
開發(fā)人員日常開發(fā)與功能測試分支篮绿。如果想正式對外發(fā)布，需在Master分支上吕漂，對Develop分支進行 "合并"（merge）操作亲配。由于Gitlab中默認對Master設置了分支保護(這個設置允許取消,如果存在多人開發(fā)的項目,不建議取消)，所以，當需要合并到Master的時候需要在Gitlab里提交合并申請由項目管理員合并吼虎。
feat-xxx
功能分支屬于臨時性分支犬钢，一般合并完就會刪除。它是為了開發(fā)某種特定功能思灰，從master分支上面分出來玷犹。開發(fā)完成后，再并入Develop分支官辈。
功能分支的名字箱舞，可以采用feat-xxx的形式命名。
bug分支
項目測試與正式發(fā)布之后拳亿，難免會出現(xiàn)bug晴股。這時就需要創(chuàng)建一個分支，進行bug修復肺魁。
-
bug出現(xiàn)環(huán)境不一樣电湘，可定義不同的bug分支。
測試環(huán)境：從develop上新建分支為fix-xxx鹅经；
正式環(huán)境：從master上新建分支為hotfix-xxx寂呛；
Gitlab分支權限管理
權限類型
GitLib有五種身份權限，分別是：
Owner 項目所有者瘾晃，擁有所有的操作權限
Master 項目的管理者贷痪，除更改、刪除項目元信息外其它操作均可
Developer 項目的開發(fā)人員蹦误，做一些開發(fā)工作劫拢，對受保護內容無權限
Reporter 項目的報告者，只有項目的讀權限强胰，可以創(chuàng)建代碼片斷
Guest 項目的游客舱沧，只能提交問題和評論內容
分支管理規(guī)范
命名規(guī)范
| 分支名稱 | 分支命名 | 功能介紹 |
|---|---|---|
| 主分支 | master | 正式環(huán)境發(fā)布 |
| 開發(fā)分支 | develop | 測試與開發(fā)環(huán)境發(fā)布 |
| 功能分支 | feat-xxx | 使用禪道的需求編號(如果對應的需求編號過多,也可以使用拼音縮寫) |
| 修復分支 | hotfix-xxx | 使用禪道的bug工單號，或者根據當前tag版本號增加 |
| 修復分支 | fix-xxx | 使用禪道的bug工單號 |
提交內容規(guī)范
Git 每次提交代碼偶洋，都要寫 Commit message（提交說明）熟吏，否則就不允許提交。但是玄窝，一般來說牵寺，commit message 應該清晰明了知押，說明本次提交的目的捉貌。提交規(guī)范設置為：" type:subject "
type
用于說明 commit 的類別炬称，只允許使用下面7個標識胁澳。
feat：新功能（feature）
fix：修補bug
style： 格式（不影響代碼運行的變動）
refactor：重構（即不是新增功能，也不是修改bug的代碼變動）
test：增加測試
subject
subject 是 commit 類型的簡短描述急鳄，不超過50個字符。
其他注意事項：結尾不加句號（.）
優(yōu)點
可讀性好乐导，清晰典阵，不必深入看代碼即可了解當前commit的作用奋渔。
為 Code Reviewing做準備
方便跟蹤工程歷史
讓其他的開發(fā)者在運行 git blame 的時候想跪謝
提高項目的整體質量，提高個人工程素質
提交分支規(guī)范
禁止向主分支直接提交代碼壮啊，包擴代碼倉庫在線編輯修改嫉鲸。特殊情況（如版本號變更、CI變更）除外歹啼；
禁止提交測試性代碼到任何主分支源碼（src）目錄玄渗，測試代碼只能存在于測試（test）目錄；
禁止任何工作分支跨主分支提交代碼狸眼，工作分支從只能合并到與工作分支同源的主分支藤树；
禁止在開發(fā)過程修改主分支版本號；
必須在代碼提交到主分支前刪除未使用的import語句和格式化代碼拓萌。
必須備注每一次提交岁钓，代碼備注必須簡要可讀。準確的描述具備可檢索性微王；
必須備注每一次合并請求屡限，對合并請求包含的功能點簡要描述。準確的描述具備可檢索性炕倘。
開發(fā)流程管理
迭代開發(fā)流程規(guī)范
總體組每周四制定下一迭代版本上線計劃并確定迭代開發(fā)主分支版本號通知到各中心（組）钧大；
各中心（組）責任人認領確認任務（截止周五），分解任務并下發(fā)開發(fā)人員罩旋，開發(fā)在新版本分支上開發(fā)啊央；
各中心（組）在周四前完成基本任務提交到迭代版本主分支交由測試組集成驗證；
測試組在集成測試分支打包測試瘸恼，bug提交到禪道管理劣挫，相關責任人及時認領并修復，同時通知測試組回歸測試东帅；
上線值日人需在每周四下班前確定最終項目版本并歸檔輸出压固；
各中心（組）責任人提交最終《數據庫變更腳本》、《環(huán)境變更腳本》通知到上線值日人靠闭；
各中心（組）責任人提交《程序變更說明》帐我、《上線驗證功能列表》到測試組；
上線值日人需要負責生產環(huán)境war包發(fā)布和數據庫變更愧膀；
測試組依據《上線驗證功能列表》驗證生產系統(tǒng)發(fā)布正確性拦键；
測試組驗證無誤依據《程序變更說明》發(fā)布上線變更通知。測試不通過通知上線值日人回滾本次發(fā)布程序和數據庫及環(huán)境變更檩淋；
總體組確定延期發(fā)布計劃芬为；
延期上線流程參照本章第五條至第十條執(zhí)行萄金；
其他時間未經批準禁止發(fā)布程序和變更數據庫操作
線上Bug修復流程
以線上版本master主分支為源創(chuàng)建hotfix-xxx的修復分支；
在hotfix-xxx的修復分支進行集成環(huán)境bug修復并向線上版本主分支提交合并請求媚朦；
中心（組）責任人負責代碼審核氧敢，同意或者拒絕本次合并請求；
測試組根據最新代碼在集成測試環(huán)境進行補丁修復驗證询张；
驗證無誤后將本次合并請求同時cherry-pick到集成迭代開發(fā)主分支孙乖；
發(fā)布流程參照【迭代開發(fā)流程規(guī)范的第五條至第十條執(zhí)行】；
測試Bug修復流程
以集成測試主分支為源創(chuàng)建fix-xxx的修復分支份氧；
在fix-xxx的修復分支進行集成環(huán)境Bug修復并向集成測試主分支提交合并請求唯袄；
中心（組）責任人負責代碼審核，同意或者拒絕本次合并請求蜗帜；
測試組根據最新代碼在集成測試環(huán)境進行補丁修復驗證恋拷；
驗證無誤后將本次合并請求cherry-pick到迭代開發(fā)主分支；
發(fā)布流程參照【迭代開發(fā)流程規(guī)范的第五條至第十條執(zhí)行】钮糖；
