最近花了一整天，認認真真地把 GitLab EE 從頭到尾建了一遍——不是那種「裝好看看首頁」的程度，而是把真實的組織架構、專案結構、Issue 流程全部搬進去跑一輪。
原因很簡單：我們團隊用 Gitea 已經一段時間了，該有的功能都有，但隨著專案越來越多、跨專案協作的需求越來越頻繁，總覺得少了點什麼。
先說結論
如果你的團隊在 10 人以下、專案數量不超過 20 個、不太需要跨專案管理——Gitea 完全夠用，而且輕量到讓你感動。
但如果你開始遇到「這個 Issue 跟那邊那個有關係」「我想看整個產品線的進度」「Label 在 A 專案跟 B 專案長得不一樣」這類問題，GitLab EE 提供的東西確實多了一個層次。
測試環境怎麼建的
為了公平比較，我不是隨便開幾個空 repo 就算了。我建了一個完整的模擬環境：
- 5 個使用者（模擬實際團隊角色：管理者、前端、後端、QA、AI 助理）
- 7 個頂層 Group + 16 個子 Group（模擬公司組織架構、客戶專案、內部工具）
- 33 個 Project，涵蓋核心框架、客戶專案、內部工具、文件庫
- 20+ 個 Issues，帶完整的標籤、指派、里程碑
- Wiki 知識庫、CI/CD 範本、Snippets
對，就是把真實的開發日常原封不動搬進去。這樣才能感受到實際用起來是什麼體驗。
Gitea 做得好的地方
先給 Gitea 說句公道話。它真的是小團隊的神器：
- 輕量到不可思議：一個 binary、一個 SQLite，5 分鐘搞定。佔用資源大概是 GitLab 的 1/10
- Git 基本功能完整：Push、PR、Code Review、分支保護，該有的都有
- API 很完整：幾乎所有操作都能透過 API 完成，自動化很方便
- 介面簡潔：不會有「功能太多找不到東西」的問題
我們用 Gitea 搭配自己寫的一些 script，跑了蠻長一段時間，基本上沒什麼大問題。
但 Gitea 缺什麼？
問題出在「跨專案」這件事。當你同時維護十幾個客戶專案，加上幾個共用的核心框架，就開始痛了：
1. 沒有 Group-level Labels
在 Gitea，每個 repo 的 Label 是獨立的。你在 A 專案建了 priority::high、type::bug，到 B 專案要重新建一次。30 幾個 repo？好，建 30 次。
而且——人是會手抖的。A 專案叫 priority::high，B 專案可能叫 priority:high（少一個冒號），C 專案叫 high-priority。三個月後你想跨專案篩選「所有高優先」，祝你好運。
GitLab 的 Group-level Labels 就是解這個痛點的。在頂層 Group 定義一次，所有子 Group 和 Project 自動繼承。改一處，全部同步。
2. 沒有 Epics
這是 GitLab EE 的殺手級功能（CE 沒有）。
舉個例子：你要做一個大功能，牽涉到後端 API、前端介面、資料庫 migration、文件更新。在 Gitea，你只能在各個 repo 開 Issue，然後在某個地方（Notion？Excel？腦子裡？）記錄「這幾個 Issue 是同一件事」。
GitLab 的 Epic 讓你把跨專案的 Issues 串在一起，有進度條、有層級關係（Epic 裡面可以有子 Epic），一眼看出整個功能做到哪了。
3. Issue Links 的深度不同
Gitea 有 Issue 的交叉引用（#123 會自動連結），但就是一個連結而已。
GitLab 的 Issue Links 有三種關係：
relates_to：相關blocks/is_blocked_by：阻擋關係
「這個前端 Issue 被後端 API 的 Issue 擋住了」——這種依賴關係在專案管理上非常重要，尤其是你的 PM 或技術主管需要判斷「先做哪個」的時候。
4. Issue Boards 的層級
Gitea 有 Project Board（看板），但只到 repo 級別。
GitLab 的 Issue Board 可以建在 Group 級別——也就是說，你可以看到整個組織、或整個客戶群組下所有專案的 Issue 狀態。對於技術主管來說，這就是「全局視野」和「一個一個 repo 點進去看」的差別。
GitLab EE 實測心得
Scoped Labels 真的好用
GitLab 的 Scoped Labels（用 :: 分隔）有一個很聰明的設計：同一個 scope 下只能選一個值。
比如 priority::high 和 priority::low 不能同時存在於同一個 Issue 上。你一選 priority::high，原本的 priority::low 就自動移除。
這聽起來是小事，但實際用起來防呆效果很好。再也不會出現「這個 Issue 同時標了 high 和 low 是什麼意思？」的情況。
Group Milestones 跨專案追進度
一個版本的 release 通常牽涉多個 repo。GitLab 的 Group Milestone 讓你建一個統一的里程碑，各 repo 的 Issue 都可以掛上去，進度一目了然。
Gitea 的 Milestone 只到 repo 級別，跨 repo 的版本管理就只能靠人工追蹤了。
Incidents 事件管理
GitLab 內建 Incident 類型的 Issue，有 severity level、timeline、專屬的管理介面。雖然小團隊可能不需要這麼正式的 incident management，但隨著客戶越來越多，「哪個客戶什麼時候出過什麼事」的追蹤確實越來越重要。
Wiki 附在 Group 上
Gitea 的 Wiki 是 per-repo 的。共用的開發規範要放哪？開一個專門放文件的 repo？
GitLab 可以在 Group 層級建 Wiki，組織層級的知識庫就有了自然的歸屬。
代價是什麼？
講了這麼多 GitLab 的好，得說說代價：
資源消耗
GitLab 是出了名的吃資源。官方建議最低 4 核 4GB RAM，實際跑起來 8GB 比較舒服。Gitea？512MB RAM 就活蹦亂跳了。
複雜度
GitLab 的設定頁面多到讓人頭暈。光是一個 Project 的 Settings 就有十幾個子頁面。Gitea 的設定大概五分鐘就能看完。
EE 授權費用
Epics、Scoped Labels 這些好東西，很多都是 EE（Premium 或 Ultimate）才有的。自架的話可以用免費的 EE 授權（功能有限），但要完整功能就得付費。
而 Gitea 完全免費開源，MIT License。
維護成本
GitLab 的升級不像 Gitea 那麼無腦。資料庫 migration、背景 job、Sidekiq、Puma⋯⋯東西多，出問題的機會也多。
那到底該選哪個？
我的判斷框架：
選 Gitea 如果：
- 團隊 < 10 人
- 專案之間相對獨立，不太需要跨專案追蹤
- 伺服器資源有限（例如跑在一台小 VPS 或 Raspberry Pi 上）
- 需求單純：程式碼管理 + PR Review + 基本 Issue 追蹤
- 預算有限，不想處理授權問題
選 GitLab EE 如果：
- 專案之間有大量交叉依賴
- 需要組織層級的管理視野（Label、Board、Milestone 都要跨專案）
- 有 PM 角色需要看全局進度
- 計畫導入 CI/CD（GitLab CI 是內建的，Gitea 需要外掛 Drone 或 Woodpecker）
- 願意投入資源維護較重的基礎設施
一個折衷方案
其實還有一個思路：Gitea 當主力 Git server，搭配外部工具補足管理功能。
比如用 Notion 或 Linear 做跨專案追蹤，Gitea 純粹負責程式碼和 PR。這樣既保留了 Gitea 的輕量優勢，又不受限於它的 Issue 管理能力。
缺點是——資訊分散在兩個系統，同步是個問題。每次開 Issue 要在兩邊都建，或者寫 webhook 自動同步，又是一筆維護成本。
最後的碎碎念
老實說，工具選型這件事沒有標準答案。重點不是「哪個比較好」，而是「哪個比較適合你現在的狀況」。
我自己的體會是：工具的選擇應該跟著團隊的成長節奏走。一開始用 Gitea 快速上手，等到管理複雜度真的到了一個臨界點，再考慮遷移到 GitLab，也不遲。
怕的是一開始就上重裝備，結果團隊花了大把時間在搞工具設定，沒時間寫 code。那就本末倒置了。
如果你也在糾結類似的選擇，希望這篇實測紀錄能幫上忙。至少可以少走一些我走過的彎路 😂