GitLab 是一個(gè)基于 git 的倉(cāng)庫(kù)管理程序茫孔，也是一個(gè)方便軟件開(kāi)發(fā)的強(qiáng)大完整應(yīng)用。
GitLab 擁有一個(gè)“用戶新人友好”的界面，通過(guò)圖形界面和命令行界面洁仗，使你的工作更加具有效率讲衫。GitLab 不僅僅對(duì)開(kāi)發(fā)者是一個(gè)有用的工具旭绒，它甚至可以被集成到你的整個(gè)團(tuán)隊(duì)中，使得每一個(gè)人獲得一個(gè)獨(dú)自唯一的平臺(tái)焦人。
GitLab 工作流邏輯符合使用者思維挥吵，使得整個(gè)平臺(tái)變得更加易用。相信我花椭，使用一次忽匈，你就離不開(kāi)它了！
GitLab 工作流
GitLab 工作流是在軟件開(kāi)發(fā)過(guò)程中矿辽，在使用 GitLab 作為代碼托管平臺(tái)時(shí)丹允，可以采取的動(dòng)作的一個(gè)邏輯序列。
GitLab 工作流遵循了提升團(tuán)隊(duì)的工作效率以及凝聚力袋倔。這種提升雕蔽，從引入一個(gè)新的項(xiàng)目開(kāi)始，一直到發(fā)布這個(gè)項(xiàng)目宾娜，成為一個(gè)產(chǎn)品都有所體現(xiàn)批狐。這就是我們所說(shuō)的“如何通過(guò)最快的速度把一個(gè)點(diǎn)子在 10 步之內(nèi)變成一個(gè)產(chǎn)品”。
軟件開(kāi)發(fā)階段
一般情況下，軟件開(kāi)發(fā)經(jīng)過(guò) 10 個(gè)主要階段嚣艇；GitLab 為這 10 個(gè)階段依次提供了解決方案：
IDEA： 每一個(gè)從點(diǎn)子開(kāi)始的項(xiàng)目承冰，通常來(lái)源于一次閑聊。在這個(gè)階段食零，GitLab 集成了Mattermost困乒。
ISSUE： 最有效的討論一個(gè)點(diǎn)子的方法，就是為這個(gè)點(diǎn)子建立一個(gè)工單討論贰谣。你的團(tuán)隊(duì)和你的合作伙伴可以在工單追蹤器issue tracker中幫助你去提升這個(gè)點(diǎn)子
PLAN： 一旦討論得到一致的同意娜搂，就是開(kāi)始編碼的時(shí)候了。但是等等吱抚！首先百宇，我們需要優(yōu)先考慮組織我們的工作流。對(duì)于此频伤，我們可以使用工單看板Issue Board恳谎。
CODE： 現(xiàn)在，當(dāng)一切準(zhǔn)備就緒憋肖，我們可以開(kāi)始寫代碼了因痛。
COMMIT： 當(dāng)我們?yōu)槲覀兊某醪匠晒麣g呼的時(shí)候，我們就可以在版本控制下岸更，提交代碼到功能分支了鸵膏。
TEST： 通過(guò)GitLab CI，我們可以運(yùn)行腳本來(lái)構(gòu)建和測(cè)試我們的應(yīng)用怎炊。
REVIEW： 一旦腳本成功運(yùn)行谭企，我們測(cè)試和構(gòu)建成功，我們就可以進(jìn)行代碼復(fù)審code review以及批準(zhǔn)评肆。
STAGING：： 現(xiàn)在是時(shí)候將我們的代碼部署到演示環(huán)境來(lái)檢查一下债查，看看是否一切就像我們預(yù)估的那樣順暢——或者我們可能仍然需要修改。
PRODUCTION： 當(dāng)一切都如預(yù)期瓜挽，就是部署到生產(chǎn)環(huán)境的時(shí)候了盹廷！
FEEDBACK： 現(xiàn)在是時(shí)候返回去看我們項(xiàng)目中需要提升的部分了。我們使用周期分析 Cycle Analytics來(lái)對(duì)當(dāng)前項(xiàng)目中關(guān)鍵的部分進(jìn)行的反饋久橙。
簡(jiǎn)單瀏覽這些步驟俄占，我們可以發(fā)現(xiàn)，提供強(qiáng)大的工具來(lái)支持這些步驟是十分重要的淆衷。在接下來(lái)的部分缸榄，我們?yōu)?GitLab 的可用工具提供一個(gè)簡(jiǎn)單的概覽。
GitLab flow
GitLab flow是GitLab官方推薦的分支管理策略祝拯，Gitlab flow 的最大原則叫做"上游優(yōu)先"（upsteam first）甚带，即只存在一個(gè)主分支master，它是所有其他分支的"上游"。只有上游分支采納的代碼變化欲低，才能應(yīng)用到其他分支辕宏。
持續(xù)發(fā)布
持續(xù)發(fā)布適用于web等可以無(wú)縫更新的項(xiàng)目畜晰。
分支約定
臨時(shí)分支：在開(kāi)發(fā)完成會(huì)被刪除
功能分支
feature- 用于新功能的開(kāi)發(fā)砾莱，建議以issue-feature-name命名修復(fù)分支
fix- 用戶bug的修復(fù)，建議以issue-fix-name命名
固定分支
開(kāi)發(fā)分支
master- 用于發(fā)布到測(cè)試環(huán)境凄鼻，上游分支為feature和fix腊瑟，該分支為受保護(hù)分支預(yù)發(fā)分支
pre-production- 用于發(fā)布到預(yù)發(fā)環(huán)境，上游分支為master正式分支
production- 用于發(fā)布到正式環(huán)境块蚌，上游分支為pre-production
使用流程
- 克隆項(xiàng)目到本地
git clone git@example.com:project-name.git
- 檢出分支
git checkout -b $issue-feature-name
- 提交并push到GitLab倉(cāng)庫(kù)
git commit -am "My feature is ready"
git push origin $issue-feature-name
- 運(yùn)行GitLab CI
- 在GitLab上創(chuàng)建一個(gè)Merge Request
- 項(xiàng)目管理者進(jìn)行代碼審查闰非，合并到
master - 運(yùn)行第二次GitLab CI
- 進(jìn)行產(chǎn)品測(cè)試
- 將
master分支合并到pre-production - 運(yùn)行第三次GitLab CI
- 進(jìn)行產(chǎn)品測(cè)試
- 將
pre-production分支合并到prouction，并且為prouction打上tag峭范，保持prouction與線上代碼一致
版本發(fā)布
版本發(fā)布適用于APP财松、小程序等有版本規(guī)劃的項(xiàng)目。
分支約定
臨時(shí)分支：在開(kāi)發(fā)完成會(huì)被刪除
功能分支
feature- 用于新功能的開(kāi)發(fā)纱控，建議以issue-feature-name命名修復(fù)分支
fix- 用戶bug的修復(fù)辆毡，建議以issue-fix-name命名
固定分支
開(kāi)發(fā)分支
master- 用于發(fā)布到測(cè)試環(huán)境，上游分支為feature和fix甜害，該分支為受保護(hù)分支發(fā)布分支
stable- 用于發(fā)布到預(yù)發(fā)環(huán)境舶掖，上游分支為master，建議以version-stable命名尔店，該分支要盡可能晚的創(chuàng)建眨攘，每次更新此分支都要更新一個(gè)小版本號(hào)
使用流程
- 克隆項(xiàng)目到本地
git clone git@example.com:project-name.git
- 檢出分支
git checkout -b $issue-feature-name
- 提交并push到GitLab倉(cāng)庫(kù)
git commit -am "My feature is ready"
git push origin $issue-feature-name
- 運(yùn)行GitLab CI
- 在GitLab上創(chuàng)建一個(gè)Merge Request
- 項(xiàng)目管理者進(jìn)行代碼審查，合并到
master - 運(yùn)行第二次GitLab CI
- 進(jìn)行產(chǎn)品測(cè)試
- 將
master分支合并到stable嚣州，如果是新版本則創(chuàng)建一個(gè)新的stable分支 - 為
stable打上tag鲫售，并進(jìn)行發(fā)布
Merge Request 合并請(qǐng)求
功能分支和修復(fù)分支合并進(jìn)master分支，必須通過(guò) Merge Request该肴。
master分支應(yīng)該受到保護(hù)情竹，不是每個(gè)人都可以修改這個(gè)分支，以及擁有審批 Merge Request 的權(quán)力沙庐。
每一次 MR 都會(huì)有一個(gè)標(biāo)題（這個(gè)標(biāo)題總結(jié)了這次的改動(dòng)）并且一個(gè)用 Markdown 書寫的描述鲤妥。在描述中，你可以簡(jiǎn)單的描述該 MR 做了什么拱雏，提及任何工單以及 MR（在它們之間創(chuàng)建聯(lián)系）棉安，并且，你也可以添加個(gè)關(guān)閉工單模式铸抑，當(dāng)該 MR 被合并的時(shí)候贡耽，相關(guān)聯(lián)的工單就會(huì)被關(guān)閉。
例如:
## 增加一個(gè)新頁(yè)面
這個(gè) MR 將會(huì)為這個(gè)項(xiàng)目創(chuàng)建一個(gè)包含該 app 概覽的 `readme.md`。
Closes #xxx and https://gitlab.com/<username>/<projectname>/issues/<xxx>
預(yù)覽：
cc/ @Mary @Jane @John
當(dāng)你創(chuàng)建一個(gè)如上的帶有描述的 MR蒲赂，它將會(huì)：
- 當(dāng)合并時(shí)阱冶，關(guān)閉包括工單
#xxx以及https://gitlab.com/<username>/<projectname>/issues/<xxx> - 展示一張圖片
- 通過(guò)郵件提醒用戶
@Mary、@Jane滥嘴，以及給@John
你可以分配這個(gè) MR 給你自己木蹬，直到你完成你的工作，然后把它分配給其他人來(lái)做一次代碼復(fù)審若皱。如果有必要的話镊叁，這個(gè) MR 可以被重新分配多次，直到你覆蓋你所需要的所有復(fù)審走触。
開(kāi)發(fā)完成后晦譬，在提交說(shuō)明里面，可以寫上"closes #67"互广。敛腌，只要commit message里面有下面這些動(dòng)詞 + 編號(hào)，就會(huì)關(guān)閉對(duì)應(yīng)的issue惫皱。
注： 添加關(guān)閉工單樣式到你的 MR 以便可以使用 GitLab 周期分析追蹤你的項(xiàng)目進(jìn)展像樊，是十分重要的。它將會(huì)追蹤“CODE”階段逸吵，衡量第一次提交及創(chuàng)建一個(gè)相關(guān)的合并請(qǐng)求所間隔的時(shí)間凶硅。
WIP MR
WIP MR 含義是 在工作過(guò)程中的合并請(qǐng)求，是一個(gè)我們?cè)?GitLab 中避免 MR 在準(zhǔn)備就緒前被合并的技術(shù)扫皱。只需要添加 WIP: 在 MR 的標(biāo)題開(kāi)頭足绅，它將不會(huì)被合并，除非你把 WIP: 刪除韩脑。
當(dāng)你改動(dòng)已經(jīng)準(zhǔn)備好被合并氢妈，編輯工單來(lái)手動(dòng)刪除 WIP: ，或者使用就像如下 MR 描述下方的快捷方式段多。
WIP 模式可以通過(guò)斜線命令 /wip 快速添加到合并請(qǐng)求中首量。只需要在評(píng)論或者 MR 描述中輸入它并提交即可。
Code Review 代碼審核
旦你創(chuàng)建一個(gè)合并請(qǐng)求进苍，就是你開(kāi)始從你的團(tuán)隊(duì)以及合作方收取反饋的時(shí)候了加缘。使用圖形界面中的差異比較功能，你可以簡(jiǎn)單的添加行內(nèi)注釋觉啊，以及回復(fù)或者解決它們拣宏。
你也可以通過(guò)點(diǎn)擊行號(hào)獲取每一行代碼的鏈接。
在圖形界面中可以看到提交歷史杠人，通過(guò)提交歷史勋乾，你可以追蹤文件的每一次改變宋下。你可以以行內(nèi)差異或左右對(duì)比的方式瀏覽它們。
如果你遇到合并沖突辑莫，可以快速地通過(guò)圖形界面來(lái)解決学歧，或者依據(jù)你的需要修改文件來(lái)修復(fù)沖突。
Issue 工單
GitLab 有一個(gè)強(qiáng)大的工單追溯系統(tǒng)各吨，在使用過(guò)程中枝笨，允許你和你的團(tuán)隊(duì)，以及你的合作者分享和討論建議绅你。所有的開(kāi)發(fā)工作都應(yīng)該以工單任務(wù)為導(dǎo)向伺帘。
工單是 GitLab 工作流的第一個(gè)重要重要特性昭躺。以工單的討論為開(kāi)始忌锯； 跟蹤新點(diǎn)子的改變是一個(gè)最好的方式。
這十分有利于：
- 討論點(diǎn)子
- 提交功能建議
- 提問(wèn)題
- 提交錯(cuò)誤和故障
- 獲取支持
- 精細(xì)化新代碼的引入
每一個(gè)在 GitLab 上部署的項(xiàng)目都有一個(gè)工單追蹤器领炫。找到你的項(xiàng)目中的 Issues > New issue 來(lái)創(chuàng)建一個(gè)新的工單偶垮。建立一個(gè)標(biāo)題來(lái)總結(jié)要被討論的主題，并且使用 Markdown 來(lái)形容它帝洪∷贫妫看看下面的“專業(yè)技巧”來(lái)加強(qiáng)你的工單描述。
GitLab 工單追蹤器提供了一個(gè)額外的實(shí)用功能葱峡，使得步驟變得更佳易于管理和考慮砚哗。下面的部分仔細(xì)描述了它。
截止日期
每一個(gè)工單允許你填寫一個(gè)截止日期砰奕。有些團(tuán)隊(duì)工作時(shí)間表安排緊湊蛛芥，以某種方式去設(shè)置一個(gè)截止日期來(lái)解決問(wèn)題，是有必要的军援。這些都可以通過(guò)截止日期這一功能實(shí)現(xiàn)仅淑。
當(dāng)你對(duì)一個(gè)多任務(wù)項(xiàng)目有截止日期的時(shí)候——比如說(shuō)，一個(gè)新的發(fā)布活動(dòng)胸哥、項(xiàng)目的啟動(dòng)涯竟，或者按階段追蹤任務(wù)——你可以使用里程碑。
受托者 Assignee
要讓某人處理某個(gè)工單空厌，可以將其分配給他庐船。你可以任意修改被分配者，直到滿足你的需求嘲更。這個(gè)功能的想法是筐钟，一個(gè)受托者本身對(duì)這個(gè)工單負(fù)責(zé)，直到其將這個(gè)工單重新賦予其他人哮内。
這也可以用于按受托者篩選工單盗棵。
標(biāo)簽 Lable
GitLab 標(biāo)簽也是 GitLab 流的一個(gè)重要組成部分壮韭。你可以使用它們來(lái)分類你的工單，在工作流中定位纹因，以及通過(guò)優(yōu)先級(jí)標(biāo)簽來(lái)安裝優(yōu)先級(jí)組織它們喷屋。
標(biāo)簽使得你與工單看板協(xié)同工作，加快工程進(jìn)度以及組織你的工作流瞭恰。
常用 Label
對(duì)于大型項(xiàng)目屯曹， 每個(gè) Issue 至少應(yīng)該有兩個(gè) Label ，一個(gè)表示性質(zhì)惊畏，另一個(gè)表示優(yōu)先級(jí)恶耽。
表示性質(zhì)的 Label，可以參考這篇文章的范例颜启。
表示優(yōu)先級(jí)的 Label偷俭，可以采用下面的級(jí)別。
- 高優(yōu)先級(jí)（High）：對(duì)系統(tǒng)有重大影響缰盏，只有解決它之后涌萤，才能去完成其他任務(wù)。
- 普通優(yōu)先級(jí)（Medium）：對(duì)系統(tǒng)的某個(gè)部分有影響口猜，用戶的一部分操作會(huì)達(dá)不到預(yù)期效果负溪。
- 低優(yōu)先級(jí)（Low）：對(duì)系統(tǒng)的某個(gè)部分有影響，用戶幾乎感知不到济炎。
- 微不足道（Trivial）：對(duì)系統(tǒng)的功能沒(méi)有影響川抡，通常是視覺(jué)效果不理想，比如字體和顏色不滿意须尚。
看板 Board
在項(xiàng)目中崖堤，GitLab 工單看板是一個(gè)用于計(jì)劃以及組織你的工單，使之符合你的項(xiàng)目工作流的工具恨闪。
看板包含了與其相關(guān)的相應(yīng)標(biāo)簽倘感，每一個(gè)列表包含了相關(guān)的被標(biāo)記的工單，并且以卡片的形式展示出來(lái)咙咽。
這些卡片可以在列表之間移動(dòng)老玛，被移動(dòng)的卡片，其標(biāo)簽將會(huì)依據(jù)你移動(dòng)的位置相應(yīng)更新到列表上钧敞。
里程碑 Milestones
里程碑 是 GitLab 中基于共同的目標(biāo)蜡豹、詳細(xì)的日期追蹤你隊(duì)伍工作的最好工具。
不同情況下的目的是不同的溉苛，但是大致是相同的：你有為了達(dá)到特定的目標(biāo)的工單的集合以及正在編碼的合并請(qǐng)求镜廉。
這個(gè)目標(biāo)基本上可以是任何東西——用來(lái)結(jié)合團(tuán)隊(duì)的工作，在一個(gè)截止日期前完成一些事情愚战。例如娇唯，發(fā)布一個(gè)新的版本齐遵，啟動(dòng)一個(gè)新的產(chǎn)品，在某個(gè)日期前完成塔插，或者按季度收尾一些項(xiàng)目梗摇。
構(gòu)建、測(cè)試以及發(fā)布
GitLab CI
GitLab CI 是一個(gè)強(qiáng)大的內(nèi)建工具想许，其作用是持續(xù)集成伶授、持續(xù)發(fā)布以及持續(xù)分發(fā)，它可以按照你希望的運(yùn)行一些腳本流纹。它的可能性是無(wú)止盡的：你可以把它看做是自己運(yùn)行的命令行糜烹。
它完全是通過(guò)一個(gè)名為 .gitlab-ci.yml 的 YAML 文件設(shè)置的，其放置在你的項(xiàng)目倉(cāng)庫(kù)中漱凝。使用 Web 界面簡(jiǎn)單的添加一個(gè)文件疮蹦，命名為 .gitlab-ci.yml 來(lái)觸發(fā)一個(gè)下拉菜單，為不同的應(yīng)用選擇各種 CI 模版碉哑。
使用案例
GitLab CI 的使用案例：
- 用它來(lái)構(gòu)建任何靜態(tài)網(wǎng)站生成器挚币，并且通過(guò) GitLab Pages 發(fā)布你的網(wǎng)站。
- 用它來(lái)發(fā)布你的網(wǎng)站 到
staging以及production環(huán)境扣典。 - 用它來(lái)構(gòu)建一個(gè) iOS 應(yīng)用。
- 用它來(lái)構(gòu)建和發(fā)布你的 Docker 鏡像到 GitLab 容器注冊(cè)庫(kù)慎玖。
我們已經(jīng)準(zhǔn)備一大堆 GitLab CI 樣例工程作為您的指南贮尖。看看它們吧趁怔！
反饋：周期分析
當(dāng)你遵循 GitLab 工作流進(jìn)行工作湿硝，你的團(tuán)隊(duì)從點(diǎn)子到產(chǎn)品，在每一個(gè)過(guò)程的關(guān)鍵部分润努，你將會(huì)在下列時(shí)間獲得一個(gè) GitLab 周期分析的反饋：
- Issue： 從創(chuàng)建一個(gè)工單关斜，到分配這個(gè)工單給一個(gè)里程碑或者添加工單到你的工單看板的時(shí)間。
- Plan： 從給工單分配一個(gè)里程碑或者把它添加到工單看板铺浇，到推送第一次提交的時(shí)間痢畜。
- Code： 從第一次提交到提出該合并請(qǐng)求的時(shí)間。
- Test： CI 為了相關(guān)合并請(qǐng)求而運(yùn)行整個(gè)過(guò)程的時(shí)間鳍侣。
- Review： 從創(chuàng)建一個(gè)合并請(qǐng)求到合并它的時(shí)間丁稀。
- Staging： 從合并到發(fā)布成為產(chǎn)品的時(shí)間。
- Production（Total）： 從創(chuàng)建工單到把代碼發(fā)布成產(chǎn)品的時(shí)間倚聚。
