Gitea 是 GitHub 上累積 58,363 顆星標與 7,231 次 fork 的開源自架 Git 服務，以 Go 語言撰寫、採用 MIT 授權，於 2016 年 11 月建立。該項目的目標是把程式碼託管、程式碼審查、議題追蹤、專案看板、Wiki、團隊協作、套件倉庫與持續整合整合為一套可以自行部署的服務，並且讓既有的 GitHub Actions 工作流程可以直接沿用。專案於 2026 年 10 月 6 日發布 v28.1.0，距離 v28.0.0 上線僅一週，儲存庫維持每日提交的活躍節奏，累計提交數超過兩萬次。
Gitea 是以 Go 撰寫的開源自架 Git 服務，把程式碼託管、審查、議題、看板、Wiki、套件倉庫與 CI/CD 整合為單一程式，採 MIT 授權，可部署於自有伺服器。
Gitea 是什麼？
它是一套自架的一站式軟體開發服務，涵蓋 Git 託管、程式碼審查、議題追蹤、專案看板、Wiki、套件倉庫與可重用 GitHub Actions 的 CI/CD。
官方把這個專案定位為「最簡單、最快速、最省心的自架一站式軟體開發服務」。使用者只需要在自己的伺服器或容器環境中啟動一個程式，就能同時得到 Git 儲存庫託管、合併請求與程式碼審查、議題與看板管理、Wiki 文件、團隊權限、各種語言的套件倉庫，以及一套與 GitHub Actions 相容的持續整合與部署流程。這種把多個獨立工具收攏到單一服務的設計，是它在自架社群中長期受到關注的主要原因。
與僅提供 Git 儲存庫的輕量方案相比，該專案的覆蓋面明顯更廣。它把議題追蹤、看板與 Wiki 視為開發流程的一部分，而不是需要另外架設的周邊系統；套件倉庫則支援 npm、Maven、Docker、Helm 等生態，讓團隊在同一個介面內即可完成從程式碼到成品封裝的流程。對於希望把開發工具鏈集中管理、又不想逐一維運多套服務的團隊而言，這種整合本身就是主要的採用理由。
由於以 Go 撰寫，該服務可以跨平台執行。官方說明其支援範圍涵蓋 Go 語言本身支援的所有平台與架構，包含 Linux、macOS、FreeBSD、OpenBSD 與 Windows，處理器架構則橫跨 x86、amd64、ARM、RISC-V 64 與 PowerPC。這種廣泛的相容性讓它可以部署在從低功耗單板電腦到大型伺服器的各種硬體之上，也讓既有的舊設備得以延續使用。
Gitea 的核心架構有什麼特點？
它以 Go 撰寫成單一可執行檔，前端採用 TypeScript 與 Vue；內建 Actions 執行器、套件倉庫與 Webhook，並可用容器或原生套件部署。
架構上，該專案把後端、前端與範本引擎打包成單一可執行檔，部署時不需要額外安裝執行環境。語言組成以 Go 為主體，前端介面使用 TypeScript、Vue 與 CSS，範本層則採用 Handlebars 風格語法。這種組合讓它同時具備後端服務的效能與網頁介面的互動性，同時把維運複雜度壓在相對較低的水準。
資料層方面，該服務可搭配多種關聯式資料庫運作，並透過快取與背景任務機制分擔壓力。它內建 Actions 執行器的管理介面，也提供 Webhook 事件通知，讓外部系統可以在儲存庫、議題或合併請求發生變動時收到訊號。v28 系列更把原本的通知機制由伺服器推送事件改為 WebSocket，改善即時更新的穩定性。
生態層面則由官方與社群共同維護。官方提供 go-sdk 開發套件、名為 tea 的命令列工具，以及 Actions 執行器；社群另有一份專案清單，收錄各種 SDK、外掛與主題，方便使用者按需求擴充。授權條款寬鬆、核心功能完整，加上可自行部署的特性，讓它在企業內網與資料主權要求較高的情境中具備吸引力。
Gitea v28 版本帶來哪些安全與網路改動？
v28.0.0 把 Git 網路操作改由內部代理處理並更新對外連線設定，推送時拒絕無效與重複物件，SSH 金鑰改用指紋比對，並收緊團隊存取與套件解除連結的授權範圍。
2026 年 9 月 29 日發布的 v28.0.0 是近期幅度最大的一次版本更新，其中最具代表性的是把 Git 的網路操作改由內部代理處理，並同步調整對外連線的出口設定。這項變動被列為破壞性變更，意味著既有部署在升級後可能需要重新檢視網路組態。官方亦在同一版本重新界定受限與保留的網路範圍，讓管理員能更精確地控制服務可以連往何處。
安全修補是這輪更新的另一重點。推送流程現在會拒絕無效與重複的 Git 物件，避免異常內容寫入儲存庫；SSH 連線改以指紋辨識使用者提供的公鑰，降低冒用風險；來自分叉的合併請求在未經核准前仍會被審批閘門攔下。此外，團隊的存取權限、儲存庫刪除與套件解除連結都改為要求儲存庫層級的授權，並更新了加密函式庫以修補一項阻斷服務漏洞。
功能面同樣有多項進展。管理員現在可以從介面、API 與命令列管理機器人帳號，個人存取權杖支援重新產生，管理員亦可暫時以特定使用者身分登入以協助排錯。稽核日誌與部署權杖等功能一併加入，讓企業環境在追溯與自動化部署上更有著力點。一周後推出的 v28.1.0 則以修正為主，處理 npm 套件相容性、數學標記渲染與分支名稱特殊字元等問題，並補上多個 API 與網頁處理器的檢查。
Gitea Actions 與套件倉庫有哪些整合能力？
它可直接重用 GitHub Actions 工作流程，v28 加入動態矩陣評估與建置佇列檢視；套件倉庫支援 npm、Maven、Docker 等生態。
該專案最受關注的整合能力，在於它的 Actions 系統可以沿用 GitHub Actions 的工作流程語法。這代表團隊既有的自動化設定不必重寫，即可搬移到自架環境執行，對於有意降低對外部平台依賴的組織而言，遷移成本因此大幅降低。v28 系列進一步支援可重用工作流程的相對路徑前綴、強制取消執行中的流程，以及針對工作流程執行的查詢與日誌端點。
在執行效率方面，新版本加入動態矩陣評估與平行上限設定，讓需要大量組合測試的專案可以更精細地控制資源。介面上則新增建置佇列檢視與成品預覽，並讓執行清單具備自適應的自動更新。這些調整回應的是實務痛點：當自動化流程成為日常，可觀測性與資源控制的重要性往往不亞於功能本身。
套件倉庫是另一條整合主線。該服務內建多種常見生態的倉庫支援，涵蓋 npm、Maven、Docker 與 Helm 等，讓團隊可以在同一套系統內發布與取用套件。v28.1.0 特別改善 npm 客戶端的相容性，v28.0.0 亦擴充了 npm 的版本中介資料與淘汰標記支援，顯示官方正持續補齊與主流工具鏈之間的落差。
如何開始自架 Gitea？
可透過官方容器映像或原生套件在自有伺服器部署，啟動後以 ./gitea web 或對應服務管理機制運行，再用瀏覽器完成初始化設定，官方另提供示範站與雲端試用。
部署路徑相當多元。官方建議使用容器映像，在 Docker 或 Podman 環境中以單一容器啟動服務，這種方式可以快速取得最新版本並簡化升級流程。偏好原生安裝的使用者則可從發行檔或套件庫取得執行檔，建置完成後以 ./gitea web 啟動服務，或透過說明指令檢視其他可用子命令。官方亦提供雲端試用與示範站，讓使用者在部署前先行體驗介面。
文件與社群支援是這個專案的優勢之一。官方文件網站涵蓋安裝、管理、使用、開發與貢獻指引，並針對靜態與動態設定選項分別說明；設定檔採 ini 格式，部分選項可於管理介面即時調整，其餘則需修改設定檔後重新啟動。專案另設有討論論壇與 Discord 伺服器，並透過 Crowdin 平台管理多語言翻譯，繁體中文與簡體中文皆有對應文件。
需要留意的是版本升級的相容性。由於 v28 涉及網路代理與出口設定的破壞性變更，既有部署在升級前應先閱讀發行說明，確認網路規則與第三方整合是否需要同步調整。這也是自架服務的共通課題：控制權提升的同時，維運與升級的責任一併轉移到團隊自身。
Gitea 的統計數據與授權條件為何？
該專案累積 58,363 顆星標、7,231 次 fork 與 491 名關注者，以 Go 撰寫、採 MIT 授權，累計提交超過兩萬次，最新版本為 v28.1.0。
授權方面，該專案採用 MIT 條款，允許商業使用、修改與再散布，僅要求保留著作權與授權聲明。這種寬鬆程度對企業相對友善，也讓它得以被整合進各種商業產品與內部平台。原始碼完全公開，議題與合併請求皆在公開儲存庫中處理，敏感的安全性問題則透過私密管道回報。
維護模式則以核心團隊加上社群貢獻者為主。官方在儲存庫中列出維護者名單，貢獻者數量接近四百人，翻譯工作由社群在 Crowdin 上協作完成。周邊另有官方與第三方專案清單，收錄命令列工具、SDK、外掛與主題。這種由核心團隊主導、社群補位的結構，是該專案能長期維持穩定更新與廣泛生態的基礎。
出處連結有哪些？
本文資訊整理自 go-gitea/gitea 的 GitHub 儲存庫與官方文件，涵蓋 v28.0.0 與 v28.1.0 發行說明、專案定位、文件網站與生態清單。
- GitHub 儲存庫：https://github.com/go-gitea/gitea
- 官方文件網站：https://docs.gitea.com/
- v28.0.0 發行說明：https://github.com/go-gitea/gitea/releases/tag/v28.0.0
- v28.1.0 發行說明：https://github.com/go-gitea/gitea/releases/tag/v28.1.0
- 生態專案清單：https://gitea.com/gitea/awesome-gitea
總結：Gitea 適合什麼團隊？
它適合重視資料主權、需要內網部署與工具鏈整合的開發團隊與中小企業；若組織高度依賴外部平台的社群網路與代管服務，則需先評估自架帶來的維運負擔。
這個專案的價值在於把軟體開發所需的多數工具收攏到一套可自行掌控的服務之中。對需要將程式碼留在自家基礎設施、又希望沿用既有 GitHub Actions 設定的團隊而言，它提供了一條遷移成本相對可控的路徑；寬鬆的授權與跨平台特性，則讓它在各類硬體與商業情境中都能落地。接近四百名貢獻者組成的社群與穩定的版本節奏，亦支撐了它長期的可用性。
不過，自架並非沒有代價。資料庫、備份、升級與網路規則都要由團隊自行負責，v28 這類涉及網路代理與出口設定的破壞性變更，更提醒使用者必須建立固定的升級檢視流程。對於習慣外部平台一站式代管、或缺乏維運人力的組織，先以容器在測試環境試用，再評估是否全面遷移，會是較穩妥的做法。