建站
咨詢
售后
建站咨詢
新聞中心
使用 Git 版本控制，是對使用它之前的所有版本控制方式的一種改進(jìn)。然而，很多組織最終以太過混亂或過于復(fù)雜的流程來結(jié)束。這個問題對于剛從其他版本控制系統(tǒng)轉(zhuǎn)過來的組織來說特別突出。
成都創(chuàng)新互聯(lián)公司是由多位在大型網(wǎng)絡(luò)公司、廣告設(shè)計(jì)公司的優(yōu)秀設(shè)計(jì)人員和策劃人員組成的一個具有豐富經(jīng)驗(yàn)的團(tuán)隊(duì)，其中包括網(wǎng)站策劃、網(wǎng)頁美工、網(wǎng)站程序員、網(wǎng)頁設(shè)計(jì)師、平面廣告設(shè)計(jì)師、網(wǎng)絡(luò)營銷人員及形象策劃。承接：網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、網(wǎng)站改版、網(wǎng)頁設(shè)計(jì)制作、網(wǎng)站建設(shè)與維護(hù)、網(wǎng)絡(luò)推廣、數(shù)據(jù)庫開發(fā),以高性價(jià)比制作企業(yè)網(wǎng)站、行業(yè)門戶平臺等全方位的服務(wù)。
在本文中我們會列出 GitLab 工作流 的11條規(guī)則，以幫助簡化、整理工作流程。這些規(guī)則最主要的益處是(或我們希望是) 它能夠簡化流程并且產(chǎn)生一個更高效和更清楚的成果。
我們認(rèn)為總會有可改善的空間，并且每一次改善都是草案。一如既往，每個人都可以做出貢獻(xiàn)!反饋和提意見是非常受歡迎的。
1. 使用功能分支，不直接提交到master。
如果你從 SVN過來，例如，你將習(xí)慣于基于trunk的工作流。當(dāng)使用Git的時(shí)候，你應(yīng)該為你做的任何事情創(chuàng)建一個分支，以便你以merge前的代碼評審作為結(jié)束。
2. 測試所有的提交，不僅僅是master上的提交。
一些人設(shè)置他們的CI僅僅測試那些被合并到master的提交。這太遲了;對于master總是綠色的測試人們應(yīng)感到有信心。對人們來說在他們開始開發(fā)新功能前不得不測試master是沒有意義的，例如，CI不是很昂貴，所以按這種方式做才有意義。
3. 在所有的提交上運(yùn)行所有的測試(如果運(yùn)行測試多于5分鐘，并行運(yùn)行它們)。
如果你工作在一個特性分支并添加新提交,然后在那個分支運(yùn)行測試。如果測試花費(fèi)較長時(shí)間，試著并行的運(yùn)行它們。在服務(wù)端的合并請求運(yùn)行所有的測試套件。如果你有一個服務(wù)于開發(fā)的測試套件，另一個僅僅是對新版本的，那么值得設(shè)置并行測試，分別運(yùn)行它們。
4. 在合并到master前執(zhí)行代碼評審，而非事后。
不要在一周結(jié)束的時(shí)候測試所有的東西。 當(dāng)場做,因?yàn)槟銜菀鬃プ】赡軐?dǎo)致問題的事情，其他人也會努力想出解決方案。
5. 部署是自動的，基于分支或基線。
如果你不想每次部署master，可以創(chuàng)建一個生產(chǎn)分支。但是這里沒有理由為什么你可能使用一個腳本或登錄到某個地方手動部署。讓一切自動化，或者一個特定的分支觸發(fā)一次生產(chǎn)部署。
6. 基線是人為創(chuàng)建，而不是CI創(chuàng)建。
用戶創(chuàng)建一個基線，基于那個基線，CI將執(zhí)行一個操作。你不應(yīng)該讓CI更改代碼倉庫。如果你需要非常詳細(xì)的指標(biāo)，您應(yīng)該有一個服務(wù)器報(bào)告列出了新版本。
7. 依賴tags版本進(jìn)行發(fā)布
如果你為你的項(xiàng)目生成tag，這表示你發(fā)布了一個新版本。
8.絕不以重置方式提交變更
如果你將一個項(xiàng)目的變更提交到一個公共的分支上，你不應(yīng)該使用重置方式(即不應(yīng)用 git rebase),
否則將造成難以追蹤你對該項(xiàng)目的改善和相應(yīng)的測試結(jié)果，這樣做實(shí)際上破壞了他人選擇最有利于的版本的依據(jù)。
我們有時(shí)也違反這條準(zhǔn)則，當(dāng)我們要求一個貢獻(xiàn)者使用(git merage --spansh)提交他的修改，以便提供真實(shí)的修改歷史，忽略他本地不規(guī)范的修改歷史時(shí)。這樣做以后查閱修改歷史時(shí)，容易根據(jù)修改歷史做版本恢復(fù)。但是總而言之 推薦做法為：代碼應(yīng)該純凈，修改歷史應(yīng)該真實(shí)。
9. 每個人都應(yīng)該從主支開始，并一直以主支為基礎(chǔ)。
這意味著你不從任何分支開始。你檢出主支內(nèi)容,然后創(chuàng)建你的特性，提交你的合并請求，下次修改還是以主支為基礎(chǔ)。在你合并內(nèi)容到主枝上時(shí)，你應(yīng)該完成審查，不應(yīng)該包含其他中間階段的內(nèi)容。
10. 先修改主支中的錯誤，之后發(fā)布分支。
如果你發(fā)現(xiàn)一個bug，最差的事是你修改了剛發(fā)布的版本，而未修改主支。
避免這種情況發(fā)生，你應(yīng)該總是先修改主枝，之后再發(fā)布另外一個版本用來修復(fù)已發(fā)布版本中的錯誤。
11. 提交的信息中反應(yīng)你修改部分的意圖
你應(yīng)該不止說明你做了什么，還應(yīng)該說明你為什么這么做。如果你解釋為什么這么做而沒有使用其他方式，這將會更有用。
本文標(biāo)題：淺析GitLabFlow的十一個規(guī)則
新聞來源：http://www.5511xx.com/article/cosghdc.html
