Stack
git.yihua.app：AI Lab 內部 AI Agents 程式碼管控
比較 GitHub、GitLab 與 Forgejo，並說明我為什麼以 Forgejo 建立 git.yihua.app，管理 AI Lab 內部 Agents 的程式碼與變更流程。
我的應用情境
git.yihua.app 是 AI Lab 內部使用的 Git 服務，主要讓 AI Agents 有一個受控的程式碼協作與版本管理入口。
我的需求不是單純找一個地方放 Git repository，而是要回答：
- 哪一個 Agent 建立了這次 commit 或 Pull Request？
- Agent 可以讀寫哪些 repository，權限能否單獨撤銷？
- 變更是否先經過測試、review 與 branch protection？
- 失敗實驗、issue、討論與決策是否能留在 repository context 中？
- 內部程式碼與 credential 是否能留在自己的基礎設施？
- 哪些成果可以安全地發布或同步到外部 GitHub？
因此我選擇 Forgejo 建立 git.yihua.app。它不是因為功能最多，而是對目前 AI Lab 而言，提供了足夠的 Git governance，同時保留自架控制與較小的維運範圍。
GitHub、GitLab、Forgejo 比較
| 面向 | GitHub | GitLab | Forgejo |
|---|---|---|---|
| 核心定位 | 大型雲端開發平台與開源協作生態 | 一體化 DevSecOps platform | 自主託管、精簡的 software forge |
| 主要部署模式 | GitHub.com SaaS；另有 Enterprise Server | GitLab.com 或 Self-Managed | Self-hosted |
| 公開社群與曝光 | 最強 | 有公開社群，但規模較小 | 以自架與 federation 社群為主 |
| Pull / Merge 流程 | Pull Request | Merge Request | Pull Request |
| CI/CD | GitHub Actions | GitLab CI/CD | Forgejo Actions 或外部 CI |
| 功能整合深度 | Apps、Actions 與 Marketplace 生態強 | CI/CD、registry、security 整合最完整 | 核心 Git collaboration 足夠且較精簡 |
| 自架成本 | Enterprise 產品與 appliance 維運 | 能力完整，但基礎資源與元件較多 | 適合小型自架環境 |
| Agent 工具相容性 | 多數工具優先支援 | API 與自動化成熟 | Git/API 可用，但部分工具需自行設定 |
| 資料控制 | GitHub.com 由外部 SaaS 託管 | Self-Managed 可自行控制 | 預設就是自行控制 |
| 我的用途 | 公開成果與外部協作 | 未來需要完整 DevSecOps 時再評估 | AI Lab 內部程式碼 control plane |
為什麼 AI Lab 選 Forgejo
1. 內部程式碼先留在內部
AI Agents 會產生大量中間版本、實驗 branch、log 與尚未審查的內容。這些資料不必預設進入外部 SaaS。Forgejo 讓 repository metadata、token 與變更紀錄先留在自己的網路與備份範圍。
2. 每個 Agent 都能有可控身分
Agent 不應共用一把全域 SSH key 或 administrator token。Forgejo 可以讓不同 automation identity 使用不同的 repository access、token scope 與 team permission；出現問題時能撤銷單一 Agent，而不是全面更換所有憑證。
3. 用 Git workflow 約束 Agent
AI Agent 可以產生程式碼，但不應因此直接取得 production merge 權限。工作 branch、Pull Request、required check、review 與 protected branch 把「能寫程式碼」和「能決定進入主要 branch」分開。
4. 維運範圍符合目前規模
GitLab 能提供更完整的 DevSecOps platform，但目前 AI Lab 首先需要的是可靠 Git、permission、Pull Request、issue、webhook 與 automation。Forgejo 的較小系統範圍更符合這個階段。
建議的 Agent 變更流程
Task / Issue
│
▼
Agent 建立工作 branch
│
▼
Commit + Push 到 git.yihua.app
│
▼
Pull Request
├── tests / lint / security checks
├── diff 與 Agent 身分紀錄
└── human 或受控 reviewer
│
▼
Merge 到 protected main
│
├── 留在 AI Lab 內部
└── 經發布檢查後 mirror / push 到 GitHub這個流程的重點不是要求每個小改動都變得官僚，而是讓高速度的 Agent 產出仍然可追蹤、可回滾、可審查。
git.yihua.app 不應做的事
- 不讓所有 Agents 共用
root或 instance administrator 權限。 - 不讓一般 coding Agent 直接管理使用者、runner 或備份。
- 不因為是內網就關閉 branch protection、token rotation 或 secret scanning。
- 不在 Forgejo server 主機直接執行來自任意 branch 的不受信任 CI job。
- 不把「已 push」視為「已 review」或「可以公開發布」。
三套服務如何並存
這不是永久只選一套 Git service：
git.yihua.app/ Forgejo：AI Lab 內部工作的 source of truth。- GitHub：公開專案、外部 contribution、社群可見性與第三方整合。
- GitLab：若未來需要更完整的自架 DevSecOps、security 與大規模 pipeline governance，再針對需求評估。
目前選 Forgejo，是選擇最適合內部 AI Agent code governance 的邊界，而不是宣稱它在所有情境都勝過 GitHub 或 GitLab。
驗證清單
- 每個 Agent 都有獨立且可撤銷的 token / SSH key
- Agent 無法直接推送 protected main
- Pull Request 能觸發實際 runner check
- Runner 無法取得 Forgejo server 或其他 repository 的多餘憑證
- Commit、Pull Request、merge 與 release 能追溯到明確身分
- Repository、database、LFS、package、設定與 secrets 有定期備份及還原演練
- 對 GitHub 的 mirror / publish credential 與內部 coding credential 分離
完成這些控制後，git.yihua.app 才不只是「能 push 的 Git server」，而是 AI Lab 真正可用的內部程式碼管控平台。