單元 4 · Merge Request 協作 · GitLab 繁中教學站

把 MR 變成「有審查、有批准、有門檻」的合併流程，是 GitLab 的強項—— 尤其 Merge Request Approvals 是它比 GitHub 更早內建、也更有彈性的功能。

MR 頁面長什麼樣

MR 頁面 · LAYOUT

┌──────────────────────────────────────┐
│ !12 修正登入頁       Open · 3 commits │
├──────────────────────────────────────┤
│ Overview   Commits   Changes   Pipelines │
│  └─ 描述（Closes #12）                │
│  └─ Reviewers / Assignees             │
│  └─ CI 狀態：✔ Pipeline passed        │
│  └─ Approval：✔ Approved by 2 人     │
│  └─ [Merge]（條件滿足才亮）            │
└──────────────────────────────────────┘

和 PR 的關鍵差異：GitLab 的 MR 頁有「Pipelines」分頁（CI 結果內嵌）、「Approvals」區塊（批准計數）——審查與自動化在同一頁整合。

Code Review · 程式碼審查

「Changes」分頁逐行檢視；GitLab 的 review 流程：

在 Changes 分頁點行號旁的「+」留言（可附建議修正 snippet）。
可以「Start a review」：先累積意見，最後一起送出。
作者修正後 push，新 commit 自動進同一 MR。

特色：GitLab 支援「resolve thread」——把已解決的討論標示完成，比 GitHub 的留言更接近「可追蹤的討論狀態」。

Merge Request Approvals · 批准機制

Approvals 規定「要幾個特定角色批准才能合併」——GitLab 最早內建此功能，且規則很細。

Approval rules · 範例規則

專案 → Settings → Merge requests → Approval rules
├── 需要 2 個批准才能合併
├── 特定檔案（如 src/payments/）必須資深者批准
└── 批准人不能是自己（code owner 例外）

GitLab 的細緻之處：可以針對「某些路徑」設不同批准人—— 例如改到金流相關程式碼，必須 CTO 批准。GitHub 需付費或靠第三方才做得到類似效果。

保護分支 · Protected Branches

與 GitHub 概念相同：防止直接 push 主分支、強制 MR 流程。

設定 · SETTINGS

專案 → Settings → Repository → Protected branches
├── 主分支（main）
├── Allowed to merge：只有維護者
└── 結合 CI + Approvals 才能合併

合併方式 · Merge Methods

方式	效果
Merge commit	保留全部 commit + 合併事件
Squash commits	壓成一個 commit（對應 GitHub 的 squash）
Rebase merge	線性重放，無合併事件

另外 GitLab 有「Merge train」：排隊依序合併，避免互相踩線（企業功能）。

看完這頁你應該能說出：

MR 頁面如何整合 CI、Approvals 與 Review。
Approvals 的規則設定與它比 GitHub 靈活之處。
保護分支設定。
三種合併方式。

MR 頁面長什麼樣

Code Review · 程式碼審查

Merge Request Approvals · 批准機制

保護分支 · Protected Branches

合併方式 · Merge Methods

延伸閱讀