事情的起因是這樣的。
最近在重新整理專案管理工具，想看看有沒有比現在更好的選擇。我們用 Gitea 自架已經一段時間了，整體沒什麼大問題，但 Issue 管理的功能比較陽春，特別是當你有多個客戶、多個專案、需要做 roadmap 規劃的時候，就會開始覺得有些地方卡卡的。
然後有人提到 GitLab EE 有 Epics、Group-level Boards、Scoped Labels⋯⋯
「聽起來不錯，不然花三天時間認真評估一下？」
就這樣，我們搭了一個示範環境，把現有的組織結構複製進去，然後開始玩。
先說評估的環境設定
我們用 GitLab EE（self-managed）搭了一個測試環境，設定如下：
- 5 個使用者
- 7 個頂層 Group（對應客戶 + 內部）
- 16 個子 Group（細分業務線）
- 33 個 Project
- 27 個 Issues（從實際案子抽樣建的）
這樣的規模基本上跟我們的真實情況差不多，評估起來比較有感覺，不是空架一個空殼就說「好用」或「不好用」。
GitLab EE 到底多了什麼
先聊聊讓我們認真考慮的功能。
Epics
這是 EE 最吸引我的功能。Epics 讓你可以跨 Project 把相關的 Issues 組織在一起，還可以設開始/結束日期、形成父子層級（Epic 底下可以有子 Epic）。
對我們來說，一個客戶的系統導入通常會橫跨多個功能模組（每個模組一個 Project），但從業務的角度看它們是同一件事。用 Epic 把這些 Issues 串起來，規劃起來直觀很多。
Scoped Labels
Scoped Labels 的語法是 scope::value，同一個 scope 底下只能選一個值。典型的用法是 status::in-progress、status::blocked、status::done——這樣 Issue 就不可能同時被標成「進行中」又「已完成」。
聽起來是個小功能，但在多人協作的情境下，這種互斥邏輯其實能省掉不少手動清理 label 的麻煩。
Group-level Boards
Gitea 的 Board 是 Project 層級的，想看整個客戶的 Issue 狀態得一個 Project 一個 Project 切換。GitLab 的 Group Board 讓你在 Group 層級直接看跨 Project 的 Issue 全貌。
這對做 sprint 規劃很有幫助——你不用為了看進度一直開分頁。
Issue Links（Blocking/Blocked by）
Issues 之間可以設依賴關係。A 完成之前 B 不能開始，這種依賴在排優先順序的時候很重要。Gitea 的 Issue 是相對獨立的，要做這種關聯要自己在 description 裡手動寫，不太正式。
但問題也不少
評估了三天之後，冷靜下來想一下。
管理複雜度上升很明顯
GitLab 的設定選項多到一個程度，光是把組織架構搭好、設定好 Group 層級的 permission、把 label 繼承邏輯搞清楚，就花了不少時間。
Gitea 的設定頁面相對簡單，一個 Org、幾個 Repo，權限設一設就能用了。GitLab 的 Group + Subgroup + Project + Member Roles + Permission inheritance⋯⋯光是搞懂這些的心智模型就要花時間。
升級路徑和版本管理
自架 GitLab 的升級路徑有時候會有版本跳躍的限制（不能跳太多版本直接升），這對自己維護的小團隊來說是個額外的心智負擔。Gitea 相對直觀，docker pull 新版本然後重起來通常沒什麼大問題。
資源需求
GitLab 比 Gitea 吃更多資源，這是已知的事情，但實際跑起來還是有感。我們的主機是 Mac Mini，平時跑 Gitea + 幾個 Docker 服務都還好，GitLab 加進來的話就要開始考慮記憶體配置了。
Epics 是 EE 專屬
Epics 這個功能在 Community Edition 裡沒有。如果你要用 EE，self-managed 的 Ultimate tier 不便宜，對一個小規模自架環境來說有點難以說服自己付這個費用。（雖然可以用免費試用期，但長期要付費就要算一下。）
Gitea 的優勢重新看了一遍
評估 GitLab 的過程中，我反而更清楚 Gitea 的優點在哪裡。
快。 Gitea 的 UI 載入速度就是快，在低資源的環境下跑起來很輕鬆。
簡單。 我們不是大公司，不需要 LDAP、Audit Log、Compliance Dashboard。Gitea 的功能剛剛好。
社群活躍、更新快。 近年 Gitea 的功能迭代滿積極的，Projects（Kanban）、Milestones、Issue 的 dependency 功能也慢慢在加。
Issues + Milestones 對我們夠用。 說實話，我們目前的痛點主要在於標籤管理比較散、還有缺乏跨 Project 視角，不是說 Gitea 的 Issues 功能本身不夠用。
最後的決定：維持 Gitea，但補一點工作流程
結論是繼續用 Gitea，但在工作流程上做一點調整：
- 統一 Label 規範：定義跨 Org 的 label 命名慣例，類似 Scoped Labels 的邏輯（
status-in-progress、status-blocked）用命名來約束 - 善用 Milestones：用 Milestone 來模擬 Epic 的概念，把相關 Issues 掛到同一個 Milestone
- 定期做跨 Project 的 Issue review：用腳本或手動整理，而不是靠工具的 Group Board
說真的，這不是 GitLab 不好——GitLab 是個很完整的平台，那些功能確實很香。但在我們現在的規模和資源限制下，Gitea 更符合「夠用、跑得快、好維護」的需求。
工具的好壞是相對於使用情境的。一個 100 人工程團隊用 GitLab EE 完全合理，但對 5 個人的小團隊來說，把精力花在把工具設定好可能不如把精力花在做產品上。
一點延伸想法
這次評估讓我想到一個更大的問題：技術工具的選擇很容易被功能清單影響，但真正決定工具好不好用的，往往是「導入成本」和「日常維護成本」。
一個功能齊全但設定繁複的工具，和一個功能簡單但三分鐘就能上手的工具——選哪個好，要看你的團隊在哪個階段。
現在選了 Gitea，不代表以後不換。等到規模真的大了、現有工具明顯卡關了，再重新評估。
但就現在來說，繼續用 Gitea，多花一點時間把工作流程訂好，這才是值得投入的地方。
如果這篇能幫你在選 Git 平台的時候多一個參考角度，那就值了。😂