當(dāng)前git是大部分開發(fā)團(tuán)隊(duì)的首選版本管理工具，一個(gè)好的流程規(guī)范可以讓大家有效地合作，像流水線一樣有條不紊地進(jìn)行團(tuán)隊(duì)協(xié)作。

業(yè)界包含三種flow：

Git flow
Github flow
Gitlab flow

下面我們先來分析，然后再看我們團(tuán)隊(duì)基于gitlab flow的最佳實(shí)踐。

◆ 從git flow到gitlab flow

◆ git flow

先說git flow，大概是這樣的。

然后，我們老的git規(guī)范是參考git flow實(shí)現(xiàn)的。

綜合考慮了開發(fā)、測試、新功能開發(fā)、臨時(shí)需求、熱修復(fù)，理想很豐滿，現(xiàn)實(shí)很骨干，這一套運(yùn)行起來實(shí)在是太復(fù)雜了。那么如何精簡流程呢？

我們來看業(yè)界的做法，首先是github flow。

◆ github flow

Github flow 是Git flow的簡化版，專門配合”持續(xù)發(fā)布”。它是 Github.com 使用的工作流程。

整個(gè)流程：

第一步：根據(jù)需求，從master拉出新分支，不區(qū)分功能分支或補(bǔ)丁分支。
第二步：新分支開發(fā)完成后，或者需要討論的時(shí)候，就向master發(fā)起一個(gè)pull request（簡稱PR）。
第三步：Pull Request既是一個(gè)通知，讓別人注意到你的請(qǐng)求，又是一種對(duì)話機(jī)制，大家一起評(píng)審和討論你的代碼。對(duì)話過程中，你還可以不斷提交代碼。
第四步：你的Pull Request被接受，合并進(jìn)master，重新部署后，原來你拉出來的那個(gè)分支就被刪除。（先部署再合并也可。）

github flow這種方式，要保證高質(zhì)量，對(duì)于貢獻(xiàn)者的素質(zhì)要求很高，換句話說，如果代碼貢獻(xiàn)者素質(zhì)不那么高，質(zhì)量就無法得到保證。

github flow這一套對(duì)于庫、框架、工具這樣并非最終應(yīng)用的產(chǎn)品來說，沒問題，但是，如果如果一個(gè)產(chǎn)品是“最終應(yīng)用”，github flow可能就不合適了。

◆ gitlab flow

Gitlab flow 是 Git flow 與 Github flow 的綜合。它吸取了兩者的優(yōu)點(diǎn)，既有適應(yīng)不同開發(fā)環(huán)境的彈性，又有單一主分支的簡單和便利。它是 Gitlab.com 推薦的做法。

Gitlab flow 的最大原則叫做”上游優(yōu)先”（upsteam first），即只存在一個(gè)主分支master，它是所有其他分支的”上游”。只有上游分支采納的代碼變化，才能應(yīng)用到其他分支。

對(duì)于”持續(xù)發(fā)布”的項(xiàng)目，它建議在master分支以外，再建立不同的環(huán)境分支。比如，”開發(fā)環(huán)境”的分支是master，”預(yù)發(fā)環(huán)境”的分支是pre-production，”生產(chǎn)環(huán)境”的分支是production。

只有緊急情況，才允許跳過上游，直接合并到下游分支。

對(duì)于”版本發(fā)布”的項(xiàng)目，建議的做法是每一個(gè)穩(wěn)定版本，都要從master分支拉出一個(gè)分支，比如2-3-stable、2-4-stable等等。

gitlab flow 如何處理hotfix？git flow之所以這么復(fù)雜，一大半原因就是把hotfix考慮得太周全了。hotfix的意思是，當(dāng)代碼部署到產(chǎn)品環(huán)境之后發(fā)現(xiàn)的問題，需要火速fix。gitlab flow 可以基于后續(xù)分支，修改后上線。

◆ 團(tuán)隊(duì)git規(guī)范

綜合上面的介紹，我們決定采用gitlab flow，按照版本發(fā)布的模式實(shí)施，具體來說：

新的迭代開始，所有開發(fā)人員從主干master拉個(gè)人分支開發(fā)特性, 分支命名規(guī)范 feature-name
開發(fā)完成后，在迭代結(jié)束前，合入master分支
master分支合并后，自動(dòng)cicd到dev環(huán)境
開發(fā)自測通過后，從master拉取要發(fā)布的分支，release-$version，將這個(gè)分支部署到測試環(huán)境進(jìn)行測試
測出的bug，通過從release-$versio拉出分支進(jìn)行修復(fù)，修復(fù)完成后，再合入release-$versio
正式發(fā)布版本，如果上線后，又有bug，根據(jù)5的方式處理
等發(fā)布版本穩(wěn)定后，將release-$versio反合入主干

◆ 最佳實(shí)踐

◆ 開發(fā)feature功能

新建分支，比如feat-test

開發(fā)代碼，增加新功能，提交：

@GetMapping(path = "/test", produces = "application/json")
	@ResponseBody
	public Map<String, Object> test() {
		return singletonMap("test", "test");
	}

git commit -m "feat: add test code"
git push origin feat-test

◆ 提交MR

提交代碼后，可以提交mr到master，申請(qǐng)合并代碼

Note：

這里可以增加自動(dòng)代碼審查,

◆ 合并代碼

研發(fā)組長，打開mr，review代碼，可以添加建議：

開發(fā)同學(xué)根據(jù)建議修復(fù)代碼，或者線下修改后commit代碼。

研發(fā)組長確認(rèn)沒有問題后，可以合并到master。

合并完成，可以刪除feat分支。

新功能開發(fā)好，可以進(jìn)行提測。

◆ 發(fā)布版本

◆ 語義化版本號(hào)

版本格式：主版本號(hào).次版本號(hào).修訂號(hào)，版本號(hào)遞增規(guī)則如下：

主版本號(hào)：當(dāng)你做了不兼容的 API 修改，次版本號(hào)：當(dāng)你做了向下兼容的功能性新增，修訂號(hào)：當(dāng)你做了向下兼容的問題修正。先行版本號(hào)及版本編譯元數(shù)據(jù)可以加到“主版本號(hào).次版本號(hào).修訂號(hào)”的后面，作為延伸。

主版本號(hào)為0，代表還未發(fā)布正式版本。

◆ 測試發(fā)布

master分支，自動(dòng)部署到開發(fā)環(huán)境（dev）

功能開發(fā)完成，并自測通過后，代碼合并到待發(fā)布版本，

分支規(guī)則：

release-version

版本規(guī)則

主版本號(hào).次版本號(hào)

構(gòu)建時(shí)，自動(dòng)增加修訂號(hào)：

主版本號(hào).次版本號(hào).修訂號(hào)

從最新的master新拉一個(gè)分支release-$version，比如release-0.1

git checkout -b release-0.1

release-$version會(huì)自動(dòng)構(gòu)建，版本號(hào)為$version.$buildNumber

設(shè)定release-$version 分支為保護(hù)分支，不允許直接推送，只能通過merge不允許直接提交代碼，接受MR。

◆ bug修復(fù)

需要修改bug時(shí)，從release-$version新拉分支，修改完成后再合并到release-$version分支.

Q: 從release-$version拉的分支，如何測試？
A: 這個(gè)節(jié)點(diǎn)定義為bug修復(fù)節(jié)點(diǎn)，建議開發(fā)同學(xué)優(yōu)先本地測試驗(yàn)證，嚴(yán)重通過再合并到release分支。
Q: release-$version太多怎么辦？
A: 可以保留最近的10個(gè)版本。歷史的打tag后，刪除分支。

來源：

https://www.toutiao.com/i6924641083897004555/

架構(gòu)師分享 高效團(tuán)隊(duì)的gitlab flow最佳實(shí)踐