go-gitea/gitea

解决什么问题

团队一旦过了「几个 Git 远程仓库」的阶段，通常就会需要代码评审、Issue、Wiki、包仓库和 CI 集中在一处。用 SaaS 要按人头付费，还得把源码交给第三方；自建 GitLab 则意味着维护一整套体积不小的 Ruby/Postgres 服务。Gitea 的做法是把这些协作能力打包成一个 Go 单二进制，从树莓派到公司虚拟机都能跑。

有什么不同

常见方案无非三种：托管 SaaS、GitLab，或者把 Gogs、独立制品库、独立 CI 拼在一起。Gitea 的取舍是「小而全」：Git 托管、Issue、看板、Wiki 和包仓库跑在同一个进程里，CI 兼容 GitHub Actions，可以直接复用现有 workflow。Go 写的另一个好处是交叉编译覆盖 Linux、macOS、BSD、Windows 以及 x86、ARM、RISC-V、PowerPC，老 ARM 设备也是合理的部署目标。代价是深度：它不打算对齐 GitLab 那套企业模块生态，README 本身也主要是外链文档，而非功能导览。

适合谁

适合中小研发团队、homelab 玩家、高校，以及有数据驻留或内网隔离要求、只想要一个「省心代码托管」的组织。你熟悉 Git，只想把周边配套自己管起来，它就是对的。反过来，如果需要深度企业集成、复杂合规审计，或者不愿意承担打补丁、备份、升级这些运维责任，那托管服务确实更省事。

上手成本

需要一台服务器，生产环境建议配独立数据库（SQLite 可用但多人场景不是好选择），还要有持续的升级纪律。官方提供容器镜像和演示站，项目自带文档站、CLI（tea）、SDK 和 Actions runner，MIT 协议很宽松，嵌入或换品牌都可以。真正的成本在安全：自建代码托管是高价值目标，该项目在 Hacker News 上最热的一条讨论是 2018 年机器人账号被入侵的事件——事情很旧，但提醒你实例加固和及时打补丁得自己负责。跨大版本升级偶有破坏性变更，上线前最好先演练迁移。

点评

这不是蹭热度的新项目：2016 年 11 月就已在 GitHub 上，约 58.7k star、7.3k fork；2026 年 10 月底还上了 Go 周榜第 7（一周 +169 star），说明关注度是稳定而非爆发式的。长期存在加上 MIT 协议，让它对想要轻量自托管 forge 的团队来说是可靠的长期依赖。它处在 SaaS 订阅和完整 GitLab 部署之间的务实位置，但没有消除运维负担——你只是把供应商管理换成了服务器管理。愿意自己管机器、想保持技术栈精简就用它；想要零维护协作，就别选。