架構(gòu)師分享 高效團(tuán)隊(duì)的gitlab flow最佳實(shí)踐
當(dāng)前git是大部分開發(fā)團(tuán)隊(duì)的首選版本管理工具，一個好的流程規(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ā)、臨時需求、熱修復(fù)，理想很豐滿，現(xiàn)實(shí)很骨干，這一套運(yùn)行起來實(shí)在是太復(fù)雜了。那么如何精簡流程呢？
我們來看業(yè)界的做法，首先是github flow。
◆ github flow
Github flow 是Git flow的簡化版，專門配合”持續(xù)發(fā)布”。它是 Github.com 使用的工作流程。
整個流程：
第一步：根據(jù)需求，從master拉出新分支，不區(qū)分功能分支或補(bǔ)丁分支。
第二步：新分支開發(fā)完成后，或者需要討論的時候，就向master發(fā)起一個pull request（簡稱PR）。
第三步：Pull Request既是一個通知，讓別人注意到你的請求，又是一種對話機(jī)制，大家一起評審和討論你的代碼。對話過程中，你還可以不斷提交代碼。
第四步：你的Pull Request被接受，合并進(jìn)master，重新部署后，原來你拉出來的那個分支就被刪除。（先部署再合并也可。）
github flow這種方式，要保證高質(zhì)量，對于貢獻(xiàn)者的素質(zhì)要求很高，換句話說，如果代碼貢獻(xiàn)者素質(zhì)不那么高，質(zhì)量就無法得到保證。
github flow這一套對于庫、框架、工具這樣并非最終應(yīng)用的產(chǎn)品來說，沒問題，但是，如果如果一個產(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），即只存在一個主分支master，它是所有其他分支的”上游”。只有上游分支采納的代碼變化，才能應(yīng)用到其他分支。
對于”持續(xù)發(fā)布”的項(xiàng)目，它建議在master分支以外，再建立不同的環(huán)境分支。比如，”開發(fā)環(huán)境”的分支是master，”預(yù)發(fā)環(huán)境”的分支是pre-production，”生產(chǎn)環(huán)境”的分支是production。
只有緊急情況，才允許跳過上游，直接合并到下游分支。
對于”版本發(fā)布”的項(xiàng)目，建議的做法是每一個穩(wěn)定版本，都要從master分支拉出一個分支，比如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拉個人分支開發(fā)特性, 分支命名規(guī)范 feature-name
開發(fā)完成后，在迭代結(jié)束前，合入master分支
master分支合并后，自動cicd到dev環(huán)境
開發(fā)自測通過后，從master拉取要發(fā)布的分支，release-$version，將這個分支部署到測試環(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，申請合并代碼
Note：
這里可以增加自動代碼審查,
◆ 合并代碼
研發(fā)組長，打開mr，review代碼，可以添加建議：
開發(fā)同學(xué)根據(jù)建議修復(fù)代碼，或者線下修改后commit代碼。
研發(fā)組長確認(rèn)沒有問題后，可以合并到master。
合并完成，可以刪除feat分支。
新功能開發(fā)好，可以進(jìn)行提測。
◆ 發(fā)布版本
◆ 語義化版本號
版本格式：主版本號.次版本號.修訂號，版本號遞增規(guī)則如下：
主版本號：當(dāng)你做了不兼容的 API 修改， 次版本號：當(dāng)你做了向下兼容的功能性新增， 修訂號：當(dāng)你做了向下兼容的問題修正。先行版本號及版本編譯元數(shù)據(jù)可以加到“主版本號.次版本號.修訂號”的后面，作為延伸。
主版本號為0，代表還未發(fā)布正式版本。
◆ 測試發(fā)布
master分支，自動部署到開發(fā)環(huán)境（dev）
功能開發(fā)完成，并自測通過后，代碼合并到待發(fā)布版本，
分支規(guī)則：
release-version版本規(guī)則
主版本號.次版本號構(gòu)建時，自動增加修訂號：
主版本號.次版本號.修訂號從最新的master新拉一個分支release-$version，比如release-0.1
git checkout -b release-0.1release-$version會自動構(gòu)建，版本號為$version.$buildNumber
設(shè)定release-$version 分支為保護(hù)分支，不允許直接推送，只能通過merge不允許直接提交代碼，接受MR。
◆ bug修復(fù)
需要修改bug時，從release-$version新拉分支，修改完成后再合并到release-$version分支.
Q: 從release-$version拉的分支，如何測試？
A: 這個節(jié)點(diǎn)定義為bug修復(fù)節(jié)點(diǎn)，建議開發(fā)同學(xué)優(yōu)先本地測試驗(yàn)證，嚴(yán)重通過再合并到release分支。
Q: release-$version太多怎么辦？
A: 可以保留最近的10個版本。歷史的打tag后，刪除分支。
來源：
https://www.toutiao.com/i6924641083897004555/