前言

GitLab 最初是 MIT 授權的免費開源軟體。現在則有 GitLab CE（社群版） 和 GitLab EE（企業版），而兩者的核心程式碼是相同的，但企業版會在核心功能之上加更多好用的進階功能，許多公司都會選擇在自家的環境架設一個 GitLab 來管理專案，今天就為大家介紹如何使用 GitLab 工作流程來進行專案開發。

個人使用者使用線上的 GitLab 除了代碼需要 public 之外，其餘功能幾乎與 GitLab EE（企業版） 相同。

GitLab 的權限控管

權限控管會由以下四個項目構成，

1. User 的 Access Level。
2. User 為特定 Project 或 Group 的 Member。
3. User 在 Project 及 Group 是哪一種 Member Permissions。
4. Project 及 Group 的 Visibility Level。

Access Level

• 一般使用者（Reguler）
• 管理者（Admin）
• 外部使用者（External users）。

Group

Group 之內可以包含多個 Project 及 Member 其中 Visibility Level 如下，

1. public: 即所有人，包含沒有登入 GitLab 的任何人都能看見此 Project 或 Group。
2. internal: 即所有的 User，都能看見此 Project 或 Group。
3. private: 只有該 Project 或 Group 的 Member 才能看見它。

Member Permissions 分別是 Guest、Reporter、Developer、Maintainer、Owner，這五種角色各自擁有權限與能執行的動作不同。

專案權限設定範例如

• 團隊內設定不同的 Member Permissions，例如資深開發者為 Maintainer，資淺者為 Developer。
• PM 與 QA 的 Member Permissions 則設定為 Reporter，可以協助回報 Issue。
• 不同開發團隊的開發者可以申請成為其他團隊的 Guest 瀏覽 Project 內容。
• 客戶的驗收窗口、外包的開發者，則以外部帳號加入特定 Project 成為 Member，並依據需求設定 Member Permissions 為 Reporter 或 Developer。

GitLab Workflow 簡介

GitLab Workflow 即是以 GitLab 為核心工具，藉助 GitLab 的產品生態系，讓開發團隊能夠有效地串連這 10 個步驟，迅速搭建團隊的 Workflow。

1. Idea: 產品創意的某個想法 (Mattermost，like Slack)
2. Issue: GitLab 的 Issue Tracker為Issue 討論空間，亦可以與實際程式碼之 commit 紀錄建立關聯。
3. Plan: 工作的優先順序。而 GitLab 的 Issue Tracker 可以直接搖身一變成為 Issue Board。
4. Code: 動手撰寫程式。
5. Commit: 送入版本控制之中。
6. Test: 自動測試，是 GitLab CI 服務的範圍了。
7. Review: 將程式碼 Merge 至主要的 Branch 之前，需要先進行 Review 的動作。
8. Staging: 將程式自動部署至 Staging 或 Production-like 的環境
9. Production: 最後即可部署至 Production 環境供使用者使用。
10. Feedback: GitLab 目前已有 Cycle Analytics 功能，可以針對專案進度、工時的控管狀況提供數據分析

建立 GitLab Issue

在項目的開發過程中會碰到很多新的需求與bug 等。這些需求與bug就是 issue 最大的來源。如果你要建立一個 issue，最好在內容主體中包含下面這些內容：

1. 用一句話描述你的需求並用它作為標題 這個需求是解決什麼問題的？
2. 這個需求對軟件現有功能會造成什麼影響？
3. 這個需求應該實現什麼樣的功能？
4. 這個需求是否依賴其他模塊提供相關支持？
5. [可選] 這個需求有哪些實現方式？
6. [可選] 這些可選的實現方式分別有哪些優缺點？

如果你要建立一個 Bug Issue，最好在內容主體中包含下面這些內容：

1. 提供出現問題的軟件版本號、操作系統環境等相關信息。
2. 提供能夠穩定復現問題的相關步驟。
3. [可選] 描述期待行為與當前行為。
4. [可選] 你對這個 bug 原因的相關分析。

當 issue 被創建後，應該等待項目的 owner 對 issue 進行 Review。如果 owner 覺得這個 issue 滿足下面的任意條件則關閉該 issue，

1. 與項目本身的功能、市場定位有衝突。
2. 與現存 issue 有重複。
3. 其他不應該被保留的情況。

Merge Request 的開發流程

在 GitLab 上創建的項目，所有人都不應該直接往 master 分支推送代碼。而是應該在其他分支（或者 fork 項目的分支）進行開發。並最終通過創建 Merge Request（類似 GitHub pull request）將代碼合併到 master 分支。

1. 開發者在自己的分支下進行開發，開發完成後，創建將該分支合併到 master 的 Merge Request，改動進入 Review 狀態。
2. 進入 Review 狀態的代碼，將由團隊內的其他一位成員（經驗比較豐富、或者對該工作模塊比較熟悉）對代碼改動進行 Code Review。
3. 大家對 Reivew 結果進行討論，並提交新的修改。
4. 最終達成一致後，代碼被 Merge 進 master 分支。

建一個Merge Request

Merge Request內容

審查完成請按下Merge按鈕，審查不通過需要按下 Close按鈕關閉這次的MR。

合併分支完成後，MR會自動關閉，需要手動關閉Issue。

結論

GitLab 能夠在 User、Issue、Commit、Merge Request 之間串聯，最重要的是 Code Review 的功能，讓專案代碼的品質獲得保障，也能為團隊在開發工作的效率上提供幫助。

下一篇介紹如何使用 Gitlab 用於處理 CI/CD 的 Pipeline。

參考

GitLab: Commit & Merge Request

Git上的三種工作流程

gitlab的工作流程