git的分支管理

1. 分支管理策略

前端採用Git Flow的分支策略，即爲功能分支策略。如下爲理想的分支管理策略，實際分支管理狀況，由各個組長肯定。相應分支功能說明以下：

1.1 master分支

主分支，該分支上的代碼，已經通過測試，而且無bug，能夠直接發版的分支。

分支合併狀況：

合併分支：test分支測試完成後，合併到master分支上。

打tag（後端處理）：要發版的時候，後端會從master分支上拉取代碼，拉取前，他們會在master分支上打一個tag。代表如今線上拉取的是這個節點代碼。

1.2 test(release)分支

測試分支（對應gitflow的預發佈分支），根據測試環境和測試功能的不一樣可能會有test、test二、test3……等多個分支。測試分支是發佈到測試環境或者灰度環境的分支。測試同事會測試上面的代碼，確保代碼沒有問題。測試經過後，在發版前，須要把測試分支的代碼合併到master分支上。

測試分支上有bug，有兩種處理方案。1是直接在test分支上改，2是從test分支上拉取新的分支hotfix_testX(x爲分支序號)_xxx（xxx爲bug名），在此分支上改。在新分支上，修改bug後再合併會test分支上。

分支合併狀況：

拉取分支：從最新的tag上從新拉取testX分支。這樣就能夠保證testX分支上代碼跟線上的代碼一致。

合併分支：拉取新的test分支後，把feature分支合併到testX分支上，發版，發版後通知測試同事測試。

上線：testX分支測試經過後，再合併到master分支。保證新功能上線。

刪除分支：test分支合併完了，刪除test分支（本地，遠程都刪除）。

目前小藥藥test分支，命名沒有語義化，命名是test、test二、test3。每個分支，對應什麼測試環境、什麼測試功能並不明確。用到時能夠問下開發。

1.3 feature分支

模塊功能分支，有時候咱們同一個系統，常常有多個功能同時開發的狀況。所以咱們須要根據不一樣的功能，拉取不一樣的分支。feature分支由組長從最新的tag上拉取，保證feature分支跟線上的一致。

feature分支命名feature-xxx(xxx爲新的功能）。

feature分支拉取完成後，能夠直接在該分支上開發，也能夠每一個人從feature分支上拉取一個本身的分支，好比feature-xxx-gxq，開發完成後再合併到feature分支上。

功能能夠提測的時候，再把feature分支合併到testX分支上，給開發測試。

分支合併狀況：

拉取分支：新功能拉取新的分支，feature分支從最新的tag上拉取，各個開發能夠在feature分支上直接開發，也能夠拉取本身的分支，開發完成以後再合併上去。

合併分支：功能開發完成後再把feature分支合併testX分支上。

刪除分支：合併分支後，刪除feature分支（本地，遠程一塊兒刪）。

1.4 hotfix分支

hotfix爲正式線的補丁分支，當線上代碼有bug的時候，須要從最新的tag上拉取一個分支來修復bug。這個分支命名一般爲hotfix-xxx(xxx爲bug名)。

開發在hotfix上修改bug後。拉取一個新的test分支。若是要拉取的分支名已經存在，問下開發這個分支有沒有人使用，沒有的話，就刪除該分支。從最新tag上拉取一個test分支，把你的hotfix分支合併到test分支，測試經過後。再把test分支合併到master分支上，同時還要把你沒有問題的hotfix分支，合併到其餘全部的test分支上和feature分支上。

分支合併狀況：

拉取分支：從最新的tag上拉取分支

合併分支：先是合併到test分支，拿去測試。測試經過後，再合併到全部的test和feature分支上。避免這些分支再合併到master上時，把之前修改過的代碼，又修改回來了。

1.5 tag說明

在重要的節點，要給分支打個tag，這樣萬一出現問題時，方便及時回滾。

1.6 其餘分支

除了以上所說的那些分支外，還有些其餘分支，好比bench（壓測）分支。這些分支通常都是從最新的tag上拉取的。當你須要更新這些分支的時候，建議直接把這個分支刪了，從新從最新的tag上拉取。若是擔憂有意外發生，能夠諮詢下開發。

另外gitflow中還推薦一個分支develop分支，咱們根據咱們實際開發須要，再也不單獨建develop分支。把master分支當develop分支使用，這樣能夠減小些流程上的麻煩。

2.分支的命名

咱們拉分支的時候，不只要知道分支是什麼功能，還須要知道分支從哪裏來，那一天創建，因爲分支不能加備註說明，由於咱們只能在分支命名上加以體現。

分支命名規則以下：

功能-模塊-來源-日期

好比saas項目，修改線上灰度會員bug的分支，就能夠命名以下：

hotfix(功能)-member(模塊)-master(來源)-1111(日期)

3.幾個須要謹記的點

1.一旦分支已經上線或者上灰度，就不能在原來的分支上改bug。改bug必須從新拉分支。避免，master上合併的修改別沖掉。

2.回滾不能使用revert命令，而是要儘可能使用reset。避免回滾以後，再合併時合併不上。

3.mergeRequest的時候，出現衝突，必定不能在gitlab上解決。gitlab上解決衝突會致使雙向merge，把合併分支上的功能合併到feature分支上。

……待補充