##背景

常見的Git開發(fā)流程中，建立好分支管理和發(fā)布規(guī)則，以及良好的日常開發(fā)分支管理，能夠較大提高開發(fā)人員效率，降低溝通維護成本，便于各個項目的codeReview，提供整個產(chǎn)品質(zhì)量。

##分支管理配置

首先，有幾條規(guī)則需要確定。

1. dev/master分支不允許直接push，向這兩個分支合并代碼需要提交MR或者PR。

所有release分支以 release#VERSION-日期 來命名，比如release#4.0-20221212 表示2022年12月12日發(fā)布的4.0分支。relase開頭的分支同樣不允許直接PUSH，必須提MR來合并代碼。

2. 客戶定制需求相關分支以? project#客戶名稱#VERSION-日期 來命名，比如 project#xinjiangkashi#4.0-20221212，表示新疆喀什的客戶分支，project開頭的分支不允許直接PUSH，必須提MR來合并代碼。

3. 新功能開發(fā)分支為 feature#原始分支名#新增功能說明，比如 feature#dev#added-spark-locality-support ，表示新功能開發(fā)，從dev分支checkout出來，新功能是增加 spark locality功能。

4. bug修復分支以 bugfix#原始分支名#修復BUG說明，比如 bugfix#release#4.0-20221212#fix-null-point-bug。

5. hotfix分支，一般僅僅作為 release或者project 分支發(fā)布后，出現(xiàn)了問題，需要緊急修復，可以創(chuàng)建該分支，創(chuàng)建規(guī)則一致。

6. feature/bugfix/hotfix提交到了一個分支后，如果該功能需要提交到其他分支，可以在頁面上操作 cherry-pick 到其他即可。

7. dev/master/release*/project*開頭的分支在git/gitlab服務端配置成保護分支，其他人就不能直接push。

##GIT workFlow示例：


##日常開發(fā)流程

>本文以dev為主要開發(fā)分支來介紹，dev分支內(nèi)包含測試過可以上線的最新代碼，根據(jù)不同情況，也可以使用master分支來做為開發(fā)主分支，遵循策略一致。

###新功能開發(fā)流程

1.從dev分支checkout出來feature分支，checkout命令：

```shell

git checkout -b feature#dev#added-locality-support

```

>說明：feature表示新功能開發(fā)，第一個#和第二個#之間內(nèi)容為checkout原始分支名稱，如果是從master分支切換出來，則為feature#master#，最后一部分內(nèi)容為feature具體新增功能。

2.編寫代碼，完成測試，測試完成后提交代碼到本地，命令：

```shell

git commit -am "added locality function."

```

3.提交代碼到遠程。

```shell

git push origin feature#dev#added-locality-support

```

4.進行CI構建，測試，測試通過后，提交MR/PR merge到dev分支，相關人員review后最終merge到dev分支。

>此處可以配置倉庫權限，只有倉庫的maintainer可以merge，其他開發(fā)人員提交MR后，maintainer需要進行codeReivew，通過后才可以merge到分支，提MR的分支必須要保證可以編譯通過，可以正常運行。

**在此條件下，dev分支任何時候去構建，都是正?？梢跃幾g通過，并且可以發(fā)布正常運行的。**

5.確認該分支是否需要 cherry-pick 到其他分支，如果需要，則操作 cherry-pick 流程到其他分支。

###bug修復流程

BUG修復流程和上述開發(fā)流程一致，僅僅是分支名稱不一樣而已，但是bug的修復要注意提交到release分支后，也需要cherry-pick到dev分支。

##Release分支管理

1. 每周從dev分支checkout出來release分支，如果發(fā)布到預發(fā)布環(huán)境，可以在分支名稱末尾增加 -rc 字樣來表示，預發(fā)布環(huán)境測試通過后，從rc分支再checkout出正式分支，發(fā)布。（此處相當于release包含兩個分支，-rc為預發(fā)布環(huán)境分支，不帶-rc為生產(chǎn)環(huán)境分支，上生產(chǎn)后，兩個分支內(nèi)容應該一致。）

2. 對project分支，如果不想維護太多project分支，對每個客戶可以只使用一個project分支，在每次發(fā)布后，增加tag來標識此次發(fā)布行為，tag僅僅做標識，不和CI結合。

3. 對于 一個分支是否需要向多個分支進行cherry-pick，需要根據(jù)業(yè)務場景來確定，比如有些定制化內(nèi)容，不需要進入dev分支，則不需要cherry-pick到dev，比如一個bugfix需要更新多個project分支和release，則需要逐個cherry-pick。

4. CI可以根據(jù)不同的分支來進行相應的構建，推薦使用gitlab CI直接可以通過不同分支的配置來進行觸發(fā)構建。