規(guī)范使用gitlab開(kāi)發(fā)
2022-04-29 13:51:37

日常開(kāi)發(fā)中使用gitlab并行開(kāi)發(fā)時(shí)，如何使各個(gè)開(kāi)發(fā)人員開(kāi)發(fā)完后提交的代碼不沖突，發(fā)布生產(chǎn)時(shí)不漏發(fā)代碼，對(duì)于我們開(kāi)發(fā)人員來(lái)說(shuō)是很重要的，也是必須掌握的，如果分支管理的不好，大家提交上來(lái)的代碼可能就會(huì)很混亂了，下面是我們公司當(dāng)前對(duì)分支使用的規(guī)范與分支使用的方法，就目前使用情況來(lái)說(shuō)，效果不錯(cuò)。

一.分支命名&使用

• master：只做為備份分支
  所有新代碼在發(fā)布完生產(chǎn)環(huán)境后，需要測(cè)試同學(xué)驗(yàn)證無(wú)誤后，將發(fā)布分支合并到master中，下一個(gè)開(kāi)發(fā)再基于master切新的開(kāi)發(fā)分支

• feature_功能名： 按功能標(biāo)識(shí)的分支
  該分支主要用于開(kāi)發(fā)某項(xiàng)功能的研發(fā)，待研發(fā)完畢后，合并到發(fā)布分支release_發(fā)布日期

• release_發(fā)布日期：安發(fā)布日期標(biāo)識(shí)的分支
  該分支主要用于發(fā)布生產(chǎn)，如release_20220429表示所有需要發(fā)布的功能代碼都要合并到該分支，該分支一般由發(fā)布日當(dāng)天從master中checkout出來(lái)

• hotfix_發(fā)布日期：按日期標(biāo)識(shí)的分支
  該分支只要用于緊急修復(fù)bug，當(dāng)日從master中checkout出來(lái)的分支，待新代碼發(fā)布到生產(chǎn)確定修復(fù)了，就將該分支合并到master中去

二.圖解過(guò)程

三.發(fā)布校驗(yàn)

當(dāng)測(cè)試人員提交了新分支的版本commit_id申請(qǐng)發(fā)布生產(chǎn)時(shí)，發(fā)布平臺(tái)需要對(duì)此分支的commit_id中代碼進(jìn)行校驗(yàn)，該步驟主要是用來(lái)確保不會(huì)漏發(fā)代碼或者刪除掉生產(chǎn)環(huán)境的代碼導(dǎo)致故障。

1. 當(dāng)前發(fā)布分支的commit_id 為該分支的最新hash
2. 當(dāng)前發(fā)布的分支中包含master中的最新hash
3. 上一次發(fā)布到生產(chǎn)的commit_id有沒(méi)有存在與當(dāng)前master分支中

對(duì)應(yīng)解釋：
1.只發(fā)發(fā)布分支的最新版本，即分支確認(rèn)需要發(fā)布后，研發(fā)人員應(yīng)該對(duì)分支進(jìn)行封版，不允許往發(fā)布分支添加新的代碼了，以免漏發(fā)代碼扯皮甩鍋
2.確保當(dāng)前的分支是基于當(dāng)前最新master中checkout出來(lái)的，即代碼是基于生產(chǎn)環(huán)境中來(lái)新增的代碼，否則可能會(huì)導(dǎo)致丟失已經(jīng)發(fā)布到生產(chǎn)環(huán)境的代碼
3.主要是校驗(yàn)上一次發(fā)布到生產(chǎn)的分支是否合到master，即確保master分支的代碼與生產(chǎn)上運(yùn)行的代碼要一致性