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標(biāo)簽，如：0.1，0.2 或 0.3。
develop 開發(fā)分支
開發(fā)人員日常開發(fā)與功能測試分支。如果想正式對外發(fā)布，需在Master分支上，對Develop分支進行 "合并"（merge）操作。由于Gitlab中默認(rèn)對Master設(shè)置了分支保護(這個設(shè)置允許取消,如果存在多人開發(fā)的項目,不建議取消)，所以，當(dāng)需要合并到Master的時候需要在Gitlab里提交合并申請由項目管理員合并。
feat-xxx
功能分支屬于臨時性分支，一般合并完就會刪除。它是為了開發(fā)某種特定功能，從master分支上面分出來。開發(fā)完成后，再并入Develop分支。
功能分支的名字，可以采用feat-xxx的形式命名。
bug分支
項目測試與正式發(fā)布之后，難免會出現(xiàn)bug。這時就需要創(chuàng)建一個分支，進行bug修復(fù)。
-
bug出現(xiàn)環(huán)境不一樣，可定義不同的bug分支。
測試環(huán)境：從develop上新建分支為fix-xxx；
正式環(huán)境：從master上新建分支為hotfix-xxx；
Gitlab分支權(quán)限管理
權(quán)限類型
GitLib有五種身份權(quán)限，分別是：
Owner 項目所有者，擁有所有的操作權(quán)限
Master 項目的管理者，除更改、刪除項目元信息外其它操作均可
Developer 項目的開發(fā)人員，做一些開發(fā)工作，對受保護內(nèi)容無權(quán)限
Reporter 項目的報告者，只有項目的讀權(quán)限，可以創(chuàng)建代碼片斷
Guest 項目的游客，只能提交問題和評論內(nèi)容
分支管理規(guī)范
命名規(guī)范
| 分支名稱 | 分支命名 | 功能介紹 |
|---|---|---|
| 主分支 | master | 正式環(huán)境發(fā)布 |
| 開發(fā)分支 | develop | 測試與開發(fā)環(huán)境發(fā)布 |
| 功能分支 | feat-xxx | 使用禪道的需求編號(如果對應(yīng)的需求編號過多,也可以使用拼音縮寫) |
| 修復(fù)分支 | hotfix-xxx | 使用禪道的bug工單號，或者根據(jù)當(dāng)前tag版本號增加 |
| 修復(fù)分支 | fix-xxx | 使用禪道的bug工單號 |
提交內(nèi)容規(guī)范
Git 每次提交代碼，都要寫 Commit message（提交說明），否則就不允許提交。但是，一般來說，commit message 應(yīng)該清晰明了，說明本次提交的目的。提交規(guī)范設(shè)置為：" type:subject "
type
用于說明 commit 的類別，只允許使用下面7個標(biāo)識。
feat：新功能（feature）
fix：修補bug
style： 格式（不影響代碼運行的變動）
refactor：重構(gòu)（即不是新增功能，也不是修改bug的代碼變動）
test：增加測試
subject
subject 是 commit 類型的簡短描述，不超過50個字符。
其他注意事項：結(jié)尾不加句號（.）
優(yōu)點
可讀性好，清晰，不必深入看代碼即可了解當(dāng)前commit的作用。
為 Code Reviewing做準(zhǔn)備
方便跟蹤工程歷史
讓其他的開發(fā)者在運行 git blame 的時候想跪謝
提高項目的整體質(zhì)量，提高個人工程素質(zhì)
提交分支規(guī)范
禁止向主分支直接提交代碼，包擴代碼倉庫在線編輯修改。特殊情況（如版本號變更、CI變更）除外；
禁止提交測試性代碼到任何主分支源碼（src）目錄，測試代碼只能存在于測試（test）目錄；
禁止任何工作分支跨主分支提交代碼，工作分支從只能合并到與工作分支同源的主分支；
禁止在開發(fā)過程修改主分支版本號；
必須在代碼提交到主分支前刪除未使用的import語句和格式化代碼。
必須備注每一次提交，代碼備注必須簡要可讀。準(zhǔn)確的描述具備可檢索性；
必須備注每一次合并請求，對合并請求包含的功能點簡要描述。準(zhǔn)確的描述具備可檢索性。
開發(fā)流程管理
迭代開發(fā)流程規(guī)范
總體組每周四制定下一迭代版本上線計劃并確定迭代開發(fā)主分支版本號通知到各中心（組）；
各中心（組）責(zé)任人認(rèn)領(lǐng)確認(rèn)任務(wù)（截止周五），分解任務(wù)并下發(fā)開發(fā)人員，開發(fā)在新版本分支上開發(fā)；
各中心（組）在周四前完成基本任務(wù)提交到迭代版本主分支交由測試組集成驗證；
測試組在集成測試分支打包測試，bug提交到禪道管理，相關(guān)責(zé)任人及時認(rèn)領(lǐng)并修復(fù)，同時通知測試組回歸測試；
上線值日人需在每周四下班前確定最終項目版本并歸檔輸出；
各中心（組）責(zé)任人提交最終《數(shù)據(jù)庫變更腳本》、《環(huán)境變更腳本》通知到上線值日人；
各中心（組）責(zé)任人提交《程序變更說明》、《上線驗證功能列表》到測試組；
上線值日人需要負(fù)責(zé)生產(chǎn)環(huán)境war包發(fā)布和數(shù)據(jù)庫變更；
測試組依據(jù)《上線驗證功能列表》驗證生產(chǎn)系統(tǒng)發(fā)布正確性；
測試組驗證無誤依據(jù)《程序變更說明》發(fā)布上線變更通知。測試不通過通知上線值日人回滾本次發(fā)布程序和數(shù)據(jù)庫及環(huán)境變更；
總體組確定延期發(fā)布計劃；
延期上線流程參照本章第五條至第十條執(zhí)行；
其他時間未經(jīng)批準(zhǔn)禁止發(fā)布程序和變更數(shù)據(jù)庫操作
線上Bug修復(fù)流程
以線上版本master主分支為源創(chuàng)建hotfix-xxx的修復(fù)分支；
在hotfix-xxx的修復(fù)分支進行集成環(huán)境bug修復(fù)并向線上版本主分支提交合并請求；
中心（組）責(zé)任人負(fù)責(zé)代碼審核，同意或者拒絕本次合并請求；
測試組根據(jù)最新代碼在集成測試環(huán)境進行補丁修復(fù)驗證；
驗證無誤后將本次合并請求同時cherry-pick到集成迭代開發(fā)主分支；
發(fā)布流程參照【迭代開發(fā)流程規(guī)范的第五條至第十條執(zhí)行】；
測試Bug修復(fù)流程
以集成測試主分支為源創(chuàng)建fix-xxx的修復(fù)分支；
在fix-xxx的修復(fù)分支進行集成環(huán)境Bug修復(fù)并向集成測試主分支提交合并請求；
中心（組）責(zé)任人負(fù)責(zé)代碼審核，同意或者拒絕本次合并請求；
測試組根據(jù)最新代碼在集成測試環(huán)境進行補丁修復(fù)驗證；
驗證無誤后將本次合并請求cherry-pick到迭代開發(fā)主分支；
發(fā)布流程參照【迭代開發(fā)流程規(guī)范的第五條至第十條執(zhí)行】；
