git分支管理模型挺多的，各類概念配圖花裏胡哨，對於初學者來講，看起來會比較累，可能理解不了。git

我這裏描述一下我我的是如何作分支管理的，有更好的方式或者建議歡迎評論區交流。github

常駐分支

保持三個常駐分支對應三個環境

master —— 生產
develop —— 開發
beta —— 測試

通常狀況下，各個公司都會有着不一樣的幾個環境用於各項研發工做markdown

名稱大同小異，我這裏截取幾個比較常見的環境名稱，分別對應生產，測試，開發併發

各位有幾個環境，通常能夠對應幾個常駐分支app

保護分支

mastergitlab

master爲保護分支，禁止直接經過本地提交，須要經由有受權的開發人員經過公司使用的git平臺合併測試

git平臺挺多的，各位的公司確定有相關的平臺選擇，github gitee gitlab gitea等等ui

建議，beta，develop分支也由平臺發起合併操做，不要在本地進行合併提交操做。url

這樣合併的過程，必定是有受權人員知曉的spa

若是有codeReview過程，這個合併期間就能作了

分支約定

命名

功能性迭代需求

採用feature/開頭。後面跟上對應的本項目版本號，不帶v

場景用例：

好比某平臺，咱們稱呼爲AAA平臺，當前已發佈的線上版本爲v6.0.0

產品A因爲某產品需求，須要對AAA平臺進行改動，則新迭代分支由master拉出爲feature/6.0.1
同期產品B因爲因爲某產品需求，須要對AAA平臺進行改動，由產品A和B協商

是合併在一個迭代內開發，仍是分開開發

合併在一塊兒，則使用feature/6.0.1開發

不然，由master從新拉出分支feature/6.0.2進行開發

兩個分支均由master拉出，互不干擾

bugfix類型需求

採用bugfix/開頭。後面跟上當前正在迭代的版本號，若是沒有正在迭代版本，則新增

場景用例：

好比AAA平臺，由代碼掃描平臺掃描發現漏洞，須要緊急修復（理論上這種問題出現的頻次相對較低）

當前AAA平臺的迭代分支爲feature/6.0.1

則從master拉取bugfix/6.0.1

修復完成後經過合併到develop,beta驗後，合併到master發佈上線
合併到master之後，將master合併到全部的迭代分支上，即且feature/6.0.1上線版本修正爲v6.0.2

分支合併流程

均由單獨的feature分支和bugfix分支往master，develop，beta分支合併

當master有新的合併後，須要將master的代碼合併到當前正在開發的迭代分支中

develop不會往beta和master合併！beta同理！

能夠視狀況而定，是否須要重建develop和beta分支

說明

這裏須要說明一下

爲何要把feature下的分支單獨往master分支合併發佈

而不是feature->develop->beta->master這樣依次合併

假設存在多個迭代同時進行，但不是同時發版。

這裏我用三個字母表明多個迭代a,b,c

他們的發版時間，分別某月1日，同月2日，同月3日。

假設在上個月30日，abc均完成迭代，發佈到了beta環境。

那麼在1日發版時，beta分支上存在b和c的代碼，沒法剝離開來單獨發版。

所以咱們毫不能採用feature/合併到develop,develop合併到beta,beta合併到master這種方式來發版

發佈流程

引入自動化平臺，可用平臺挺多的，jenkins spug等等

由自動化平臺拉取master分支進行發佈
上線驗證完畢之後
git平臺發佈release，生成tag填寫版本好，帶v
必定要填寫本次發版內容！！！
刪除對應迭代分支

對於某些由主幹產品單獨定製的業務產品

可能存在某些業務，又一個主幹產品

同時有些客戶要求定製化

這些定製化之後的需求，實際上就偏離了主幹產品了

針對這種類型的產品，經過fork的方式拉出單獨倉庫，按照上述方式進行分支管理

由於經過fork方式，定製項目與主幹項目存在關聯性

能夠經過合併的方式，將主幹的某些內容合併到定製項目上

對於這類項目的發佈，均由自動化平臺的單獨業務job發佈

我是怎麼作git分支管理的