安裝與環境選擇#

GitLab 提供多種安裝方式，每種適合不同的場景：

• Package Management（Omnibus）：官方推薦的標準安裝方式，
  一個套件包含所有元件（Nginx、PostgreSQL、Redis 等），最適合正式環境
• Docker：適合快速試用、開發環境或已有容器基礎設施的團隊
• Kubernetes Helm Chart：適合大規模部署與高可用需求

初次接觸建議用 Docker 快速跑起來體驗功能，正式環境再考慮 Omnibus 或 Kubernetes 部署。

Admin Area 管理後台#

管理後台是 GitLab 管理員的控制中心，涵蓋：

• 系統監控：查看系統健康狀態、背景任務佇列
• 使用者管理：新增/停用帳號、設定角色
• 全域設定：預設分支保護、註冊限制、CI/CD 配額

如果你是團隊的 GitLab 管理員，花時間熟悉 Admin Area 是值得的投資。
許多團隊問題（Runner 不足、儲存空間告警）都需要在這裡處理。

使用者與權限控管#

GitLab 的權限模型分為五個層級：

1. Guest：只能查看 Issue，無法存取程式碼
2. Reporter：可查看程式碼，但不能推送
3. Developer：可推送程式碼、建立 Merge Request
4. Maintainer：可合併 MR、管理分支保護規則
5. Owner：專案或群組的最高權限

權限設計的原則是最小權限。
一般開發者給 Developer 角色即可，只有需要管理專案設定的人才給 Maintainer。
Owner 應限制在極少數人手中。

Omnibus GitLab#

Omnibus 是 GitLab 官方的整合安裝套件，值得了解的關鍵點：

• 所有設定集中在 /etc/gitlab/gitlab.rb，修改後執行 gitlab-ctl reconfigure 即可套用
• 內建備份機制：gitlab-backup create 可產生完整備份
• 支援元件拆分：可以把 PostgreSQL、Redis 等拆到獨立主機

gitlab-ctl reconfigure 會重新產生設定檔並重啟服務，在正式環境執行前務必在維護窗口進行。

Mattermost 協作平台#

GitLab 內建整合了 Mattermost（類似 Slack 的開源通訊平台）：

• 可直接從 Omnibus 啟用，無需另外安裝
• 支援 GitLab SSO 登入
• 可設定 Webhook 接收 CI/CD 通知、Merge Request 事件

如果團隊已經有 Slack 或 Microsoft Teams，不一定需要啟用 Mattermost。
但對於希望所有工具都自架的團隊，這是一個方便的選項。

開發者的行動指南#

1. 第一個專案：建立專案後，先設定好分支保護規則與 Merge Request 流程
2. SSH Key 設定：確保每位開發者都設定好 SSH Key，避免每次推送都輸入密碼
3. 權限規劃先行：在團隊成員加入前，先設計好 Group 結構與權限層級