如何淺析GitLab Flow的十一個(gè)規(guī)則

本篇文章為大家展示了如何淺析GitLab Flow的十一個(gè)規(guī)則，內(nèi)容簡(jiǎn)明扼要并且容易理解，絕對(duì)能使你眼前一亮，通過(guò)這篇文章的詳細(xì)介紹希望你能有所收獲。

使用 Git  版本控制，是對(duì)使用它之前的所有版本控制方式的一種改進(jìn)。然而，很多組織最終以太過(guò)混亂或過(guò)于復(fù)雜的流程來(lái)結(jié)束。這個(gè)問(wèn)題對(duì)于剛從其他版本控制系統(tǒng)轉(zhuǎn)過(guò)來(lái)的組織來(lái)說(shuō)特別突出。

我們會(huì)列出 GitLab 工作流 的11條規(guī)則，以幫助簡(jiǎn)化、整理工作流程。這些規(guī)則最主要的益處是(或我們希望是)  它能夠簡(jiǎn)化流程并且產(chǎn)生一個(gè)更高效和更清楚的成果。

我們認(rèn)為總會(huì)有可改善的空間，并且每一次改善都是草案。一如既往，每個(gè)人都可以做出貢獻(xiàn)!反饋和提意見(jiàn)是非常受歡迎的。

1. 使用功能分支，不直接提交到master。

如果你從  SVN過(guò)來(lái)，例如，你將習(xí)慣于基于trunk的工作流。當(dāng)使用Git的時(shí)候，你應(yīng)該為你做的任何事情創(chuàng)建一個(gè)分支，以便你以merge前的代碼評(píng)審作為結(jié)束。

2. 測(cè)試所有的提交，不僅僅是master上的提交。

一些人設(shè)置他們的CI僅僅測(cè)試那些被合并到master的提交。這太遲了;對(duì)于master總是綠色的測(cè)試人們應(yīng)感到有信心。對(duì)人們來(lái)說(shuō)在他們開(kāi)始開(kāi)發(fā)新功能前不得不測(cè)試master是沒(méi)有意義的，例如，CI不是很昂貴，所以按這種方式做才有意義。

3. 在所有的提交上運(yùn)行所有的測(cè)試(如果運(yùn)行測(cè)試多于5分鐘，并行運(yùn)行它們)。

如果你工作在一個(gè)特性分支并添加新提交,然后在那個(gè)分支運(yùn)行測(cè)試。如果測(cè)試花費(fèi)較長(zhǎng)時(shí)間，試著并行的運(yùn)行它們。在服務(wù)端的合并請(qǐng)求運(yùn)行所有的測(cè)試套件。如果你有一個(gè)服務(wù)于開(kāi)發(fā)的測(cè)試套件，另一個(gè)僅僅是對(duì)新版本的，那么值得設(shè)置并行測(cè)試，分別運(yùn)行它們。

4. 在合并到master前執(zhí)行代碼評(píng)審，而非事后。

不要在一周結(jié)束的時(shí)候測(cè)試所有的東西。 當(dāng)場(chǎng)做,因?yàn)槟銜?huì)更容易抓住可能導(dǎo)致問(wèn)題的事情，其他人也會(huì)努力想出解決方案。

5. 部署是自動(dòng)的，基于分支或基線。

如果你不想每次部署master，可以創(chuàng)建一個(gè)生產(chǎn)分支。但是這里沒(méi)有理由為什么你可能使用一個(gè)腳本或登錄到某個(gè)地方手動(dòng)部署。讓一切自動(dòng)化，或者一個(gè)特定的分支觸發(fā)一次生產(chǎn)部署。

6. 基線是人為創(chuàng)建，而不是CI創(chuàng)建。

用戶創(chuàng)建一個(gè)基線，基于那個(gè)基線，CI將執(zhí)行一個(gè)操作。你不應(yīng)該讓CI更改代碼倉(cāng)庫(kù)。如果你需要非常詳細(xì)的指標(biāo)，您應(yīng)該有一個(gè)服務(wù)器報(bào)告列出了新版本。

7. 依賴tags版本進(jìn)行發(fā)布

如果你為你的項(xiàng)目生成tag，這表示你發(fā)布了一個(gè)新版本。

8.絕不以重置方式提交變更

如果你將一個(gè)項(xiàng)目的變更提交到一個(gè)公共的分支上，你不應(yīng)該使用重置方式(即不應(yīng)用 git rebase),

否則將造成難以追蹤你對(duì)該項(xiàng)目的改善和相應(yīng)的測(cè)試結(jié)果，這樣做實(shí)際上破壞了他人選擇最有利于的版本的依據(jù)。

我們有時(shí)也違反這條準(zhǔn)則，當(dāng)我們要求一個(gè)貢獻(xiàn)者使用(git merage  --spansh)提交他的修改，以便提供真實(shí)的修改歷史，忽略他本地不規(guī)范的修改歷史時(shí)。這樣做以后查閱修改歷史時(shí)，容易根據(jù)修改歷史做版本恢復(fù)。但是總而言之  推薦做法為：代碼應(yīng)該純凈，修改歷史應(yīng)該真實(shí)。

9. 每個(gè)人都應(yīng)該從主支開(kāi)始，并一直以主支為基礎(chǔ)。

這意味著你不從任何分支開(kāi)始。你檢出主支內(nèi)容,然后創(chuàng)建你的特性，提交你的合并請(qǐng)求，下次修改還是以主支為基礎(chǔ)。在你合并內(nèi)容到主枝上時(shí)，你應(yīng)該完成審查，不應(yīng)該包含其他中間階段的內(nèi)容。

10. 先修改主支中的錯(cuò)誤，之后發(fā)布分支。

如果你發(fā)現(xiàn)一個(gè)bug，最差的事是你修改了剛發(fā)布的版本，而未修改主支。

避免這種情況發(fā)生，你應(yīng)該總是先修改主枝，之后再發(fā)布另外一個(gè)版本用來(lái)修復(fù)已發(fā)布版本中的錯(cuò)誤。

11. 提交的信息中反應(yīng)你修改部分的意圖

你應(yīng)該不止說(shuō)明你做了什么，還應(yīng)該說(shuō)明你為什么這么做。如果你解釋為什么這么做而沒(méi)有使用其他方式，這將會(huì)更有用。

上述內(nèi)容就是如何淺析GitLab Flow的十一個(gè)規(guī)則，你們學(xué)到知識(shí)或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識(shí)儲(chǔ)備，歡迎關(guān)注億速云行業(yè)資訊頻道。