Forgejo | 益華嚴選工具箱

我為什麼選 Forgejo

我在 git.yihua.app 使用 Forgejo，主要用途不是建立另一個公開 GitHub，而是作為 AI Lab 內部 AI Agents 的程式碼 control plane。

AI Agents 可以很快產生大量 commit、branch 與實驗性修改，也可能需要自動建立 repository、issue、Pull Request、tag 或 release。這些能力如果只靠共用 SSH key、散落的 working directory 或直接寫入主要 branch，很難知道是哪個 Agent 做了什麼，也很難撤銷權限與回溯決策。

Forgejo 提供的是一個我可以自己掌握的 Git 服務邊界：repository、帳號、token、permission、review、webhook、Actions 與 audit context 都留在 AI Lab 的控制範圍。

Forgejo 不是 AI 專用 Git

Forgejo 本身是一套通用 software forge，並不會自動理解 AI Agent，也不會替 Agent 做安全判斷。

它適合這個用途，是因為我可以把每個 Agent 當成獨立的 automation identity，使用 repository-scoped token、SSH key、team permission 與 branch protection 限制它能做的事，再用 Pull Request、check 與人工 review 決定變更能否進入主要 branch。

AI Agent
   │ scoped token / SSH key
   ▼
git.yihua.app / Forgejo
   ├── repository + branch
   ├── issue / Pull Request
   ├── webhook / Forgejo Actions
   └── review + merge policy

和 GitHub 的取捨

GitHub 擁有更大的公開社群、Marketplace 與第三方整合；公開專案、外部協作與上游 contribution 仍然更適合 GitHub。

git.yihua.app 則優先解決內部控制：AI Lab 的實驗 repository 不需要預設離開自己的基礎設施，Agent token 不需要對 GitHub.com 取得廣泛權限，也能在發布前先把內部變更整理乾淨。

和 GitLab 的取捨

GitLab Self-Managed 提供更完整的一體化 DevSecOps 能力，但相對需要更多資源與平台維運。Forgejo 的功能面較小，對目前 AI Lab 需要的 Git、Pull Request、issue、permission、webhook、package 與 automation 已足夠，也更容易維持單純的故障範圍。

AI Agent 權限原則

自架不代表可以忽略權限。我會把 git.yihua.app 的 Agent 使用方式限制為：

每個 Agent 或 automation workflow 使用獨立身分，不共用管理者 token。
Token 只授予必要 repository 與必要 scope，並設定輪替與撤銷流程。
Agent 預設推送工作 branch，不直接 force-push 或刪除主要 branch。
主要 branch 使用 protection、required check 與 Pull Request review。
執行不受信任程式碼的 runner 和 Forgejo server 分離，避免 CI job 取得 forge 主機控制權。
Repository、database、設定、LFS / package data 與金鑰都要有可還原的備份。
對外發布到 GitHub 前，再做 secret scan、license 與內容檢查。

目前的定位

git.yihua.app 是 AI Lab 的內部程式碼系統，不是 GitHub 的全面替代品。

Forgejo 保存 AI Agents 的工作過程與內部 repository；GitHub 負責需要公開生態與外部協作的成果。兩者可以透過受控 mirror 或 release workflow 連接，但不應讓內部 Agent 憑證直接等同公開發布權限。

參考：Forgejo repository permissions、Forgejo Actions、Forgejo access token scope