在 gitea vs forgejo vs onedev 的对比中，你面对的其实是回答两个不同问题的三款工具。Gitea 和 Forgejo 是在 git 服务器上外挂了项目管理功能。OneDev 则是一个项目管理加 CI 平台，恰好也把 git 托管做得很好。所以这不是“这三者哪个最好”的问题，而是“我想要一个小巧的 git 服务器，还是一个一体化平台，以及我能否承受一体化平台所需的 RAM 开销”的问题。
最后这一点正是矛盾所在。OneDev 开箱即用的功能更多，而 nodatools.com 的测试显示，其空闲时的内存占用大约是纯净版 Forgejo 安装的 3 倍，在小型 VPS 上这可能会让你的月度账单翻倍。这个取舍就是问题的全部核心。（另外说明一下，GitLab 不在本次对比之列。如果你想了解 GitLab 的资源占用情况，也不会来看这三者的比较。）
我这三款都实际用过。以下是当你为团队做选择时真正重要的内容：把 Gitea 和 Forgejo 区分开来的治理结构与许可证差异、能证明 OneDev 存在价值的功能、经过实测的 RAM 数字，以及针对每一款给出的直白的“如果……就选它”建议。
TL;DR（太长不看版）
- 想要一个带 Actions 风格 CI 的轻量级 git 服务器？ Gitea 或 Forgejo。如果更接近 GitHub Actions 的兼容性对你很重要，就选 Gitea；如果可以接受类似 GitHub 的 workflow 语法外加一些迁移调整，就选 Forgejo。
- 在意非营利治理结构或 copyleft 许可证？ Forgejo。它是由社区治理的分叉版本，也是我为大多数团队推荐的默认选择。
- 想要 MIT 许可证、最大的代码托管社区，或者带有 SLA/SSO 的付费 Enterprise 版本？ Gitea。
- 想要一次安装就拥有内置项目管理、内置 CI 和代码智能分析，而且有足够的 RAM 可以挥霍？ OneDev。只需知道它至少需要约 4 GB，而 Forgejo 有 1 GB 就足够用得很舒服。
快速结论： 对大多数团队来说，Forgejo 是资源占用小的合理默认选择：核心与 Gitea 相同，治理结构更清晰，Forgejo Actions 还提供了类似 GitHub 的 workflow 语法。只有当你确实想要 PM 加 CI 捆绑在一起的体验，并且不需要迁移大量已有的 GitHub Actions workflow 时，才应该选择 OneDev。
这三款工具要回答的两个问题
OneDev 把它的 CI 构建守护进程运行在 OneDev 进程内部，因此不需要单独部署 runner。Gitea 和 Forgejo 则相反：git 服务器是一回事，你需要在它旁边把 CI runner 部署成一个独立的进程。这一单一的架构事实，正是每个工具如何看待自身的写照。
Gitea 和 Forgejo 都是以 git 为先。仓库、pull request 和代码评审是核心；issue 和看板是有用的附加功能；CI 则是你外挂上去的东西。整个设计都是围绕托管 git、并且不挡你的路来展开的。这就是它们体积小、速度快、运行成本低的原因。
OneDev 的构建思路正好相反。它是一个项目管理与 CI/CD 平台，git 托管是其中的一等公民，但并不是组织原则。看板是自动化的，CI 是内嵌的，代码智能是内置的，它期望成为你团队生活的地方，而不仅仅是代码存放的地方。这是一款本质上不同的产品，这也是为什么拿它和 Gitea 比“谁的 git 托管做得更好”会偏离重点。它们在 git 托管上做得差不多好。OneDev 只是想做更多事情，而它为此向你收取的代价，就是资源开销。
后续的一切都可以归结到这个分野上。Gitea 与 Forgejo 的选择，是“轻量级代码托管平台”这一分支内部的子决策。而“OneDev 值不值得用”则完全是另一个分支的问题。
Gitea vs Forgejo：一场近乎孪生的抉择
两者的 RAM 占用都在 180–350 MB 左右，在分叉点之前共享同一套代码库，核心 git 托管方式也完全一样。在仓库、pull request、代码评审、issue 以及 Actions 风格的 CI 方面，除非你要迁移已有的 GitHub Actions workflow，否则日常使用中你很难找到有意义的差异。所以先把话说清楚：这不是一场功能之争。onedev 与 gitea 之间的差距很大；而 gitea 与 forgejo 之间的差距，关乎的是谁掌控这个项目，以及它以何种许可证发布。
这是你真正需要了解的背景。2022 年 10 月，Gitea 的域名和商标成为一场治理纠纷的焦点，Forgejo 应运而生。Forgejo 现在隶属于 Codeberg e.V.，一家位于德国的非营利组织，并以 GPL-3.0 许可证发布。Gitea 仍然是 MIT 许可，拥有免费的开源自托管版本，而 CommitGo 则在此基础上销售 Gitea Enterprise。 Forgejo 是这样描述这一安排的 为 Open Core；Gitea/CommitGo 对这一说法有异议，并表示开源的 Gitea 项目本身并不包含专有代码。对读者来说，实际的差异比这场路线之争简单得多：Forgejo 追求的是非营利、copyleft、完全免费的治理模式；Gitea 提供的是宽松的 MIT 核心，外加厂商支持的 Enterprise 路径。
由此引出三个结论，每一个都会影响你的决策：
- 许可证。 GPL-3.0 copyleft（Forgejo）意味着，如果你修改了 Forgejo 并分发修改后的版本，就必须在 GPL 许可下公开你的改动。MIT（Gitea）没有这个要求。对于大多数在内部运行未修改实例的团队来说，这个问题根本不会出现。但如果你是在这个代码托管平台之上进行二次开发并将其发布出去，这一点就很重要。
- 安全披露。 Forgejo 通过公开渠道向所有人通报安全公告。Gitea 则把提前的安全通知保留给付费的 Enterprise 客户，这意味着使用免费层的自托管管理员，暴露在已知漏洞下的时间可能比付费客户更长。如果你运行的是免费版本，这种不对等是值得了解的。
- 其中一方存在付费层级。 Gitea 有一个商业版 Enterprise Edition（每用户每月 9.50–19 美元），增加了 SSO、审计日志、优先支持和 SLA。Forgejo 没有付费层级，所有功能都在免费的 GPL 版本中。
如果你现在正在使用 Gitea，而这篇文章让你倾向于转向 Forgejo，好消息是有一条受支持的迁移路径（在 Gitea 1.22 处存在一个版本断层，值得在开始之前先弄清楚）。我另外单独写了一篇文章，参见 完整的迁移演练 查看逐版本的详细说明。如果你正打算从 GitHub 迁移出来，还没决定用哪个代码托管平台，那是一个独立的决策，有其自身的取舍，值得单独去梳理。
本节要点：在核心 git 托管功能上，Gitea 和 Forgejo 不相上下。如果你想要非营利性质的所有权、copyleft 许可以及公开的安全披露，选择 Forgejo；如果你想要 MIT 许可证、更大的社区，或商业化的 Enterprise 版本，选择 Gitea。
OneDev 真正与众不同之处
运行 OneDev（截至撰写本文时为 16.0.1）一天后，你会注意到的第一件事是：你从未部署过 CI runner。构建守护进程就内置在 OneDev 服务器里，所以平台一启动 CI 就能用。你可以在 GUI 里搭建流水线而不用写一行 YAML，通过网页终端调试任务，甚至在推送之前就针对本地未提交的改动测试构建。相比 Gitea 和 Forgejo 要求的那套“先装服务器，再单独安装并注册 runner”的流程，这确实是运维上的简化。
问题在于（对现有团队来说这是个不小的问题），OneDev 使用的是自己的一套 YAML 方言。它 不是 兼容 GitHub Actions。你为 GitHub、Gitea 或 Forgejo 编写的每一个 workflow，都必须重写才能在 OneDev 上运行。如果你依赖一堆 .github/workflows 文件，这就是真正的迁移成本，而不是可以一笔带过的小事。Gitea 和 Forgejo 都继承了 GitHub Actions 生态，但继承的方式并不相同。Gitea Actions 的设计目标就是作为 GitHub Actions 的直接替代，因此大多数 workflow 无需修改即可迁移。Forgejo 的 runner 在实践中也兼容，但存在已记录的差异：缺少 permissions 子键、continue-on-error 被忽略、OIDC 语法不同。在假设完全可移植之前，先检查这些差异。
OneDev 做到而那些更轻量的代码托管平台做不到的第二件事：网页 UI 中的代码智能分析。符号搜索、跳转到定义、查找引用等功能，无需在本地克隆仓库即可在多种语言中使用（官方列表包括 Java、JavaScript、C、C++、C#、Go、PHP 和 Python）。Gitea 和 Forgejo 都没有内置类似功能，你得借助外部工具。如果你的团队经常在浏览器里做代码审查，这个功能确实很有用。
再加上全自动看板（基于规则的任务流转、自定义状态和字段、转换规则）、一个能把收到的邮件直接转成 issue 而无需发件人拥有账号的服务台，以及公开项目中的机密 issue，整体画面就清晰了：OneDev 想要同时充当你的 issue 跟踪系统、CI 系统、代码浏览器和项目看板。
关于软件包仓库，有一点值得澄清。OneDev 内置了一个仓库，这一点是明确的。它的 软件包教程 列出了 Docker、npm、NuGet、Maven、PyPI 和 RubyGems，而当前的产品介绍中还提到了 Helm。Gitea 和 Forgejo 覆盖的包格式范围要广得多，包括 Alpine、Arch、Cargo、Composer、Conan、Conda、Debian、Go、Helm、Maven、npm、NuGet、PyPI、RPM、RubyGems、Swift、Vagrant 等等。如果你的团队依赖的包格式不在 OneDev 这套较窄的仓库支持范围内，Gitea 或 Forgejo 是更稳妥的选择。
本节要点：OneDev 一次安装就能带来内置 CI、代码智能分析和完整的项目管理套件。代价是你需要重写所有 GitHub Actions 工作流、接受更小的生态系统，并且（下一节会讲到）要为它投入多得多的 RAM。
资源成本：每一款工具实际需要多少资源
对许多团队来说，决定整个对比结果的关键数字来自 nodatools.com 的测试：OneDev 空闲时占用约 600 MB RAM，而 Forgejo 空闲时约为 180 MB。这是 3 倍以上的差距，而且在负载下差距还会进一步拉大。以下是他们的实测数据，来自 nodatools.com's measured comparison，在全新的 VPS 上运行：
| 工具 | 当前版本 | 空闲 RAM 占用（已测试） | 负载下的实际 RAM 占用（已测试） | 官方最低要求 |
|---|---|---|---|---|
| Forgejo | v15.0.3 LTS | ~180 MB | ~320 MB | 512 MB |
| Gitea | 1.26.4 | ~200 MB | ~350 MB | 512 MB |
| OneDev | 16.0.1 | ~600 MB | ~950 MB | 2 GB |
为什么会有这个差距？OneDev 主要是用 Java 编写的，因此 JVM 会带来堆内存开销，而基于 Go 的 Gitea 和 Forgejo 根本没有这个负担。除此之外，OneDev 会为其智能分析功能对代码建立索引，而初始索引过程非常吃内存。我第一次搭建它的时候，启动阶段的内存飙升是最吓人的部分，但那并不是稳定运行时的状态。
小贴士：不要被 OneDev 启动时的内存占用吓到。在启动后 JVM 预热、初始代码索引构建期间，内存可能会短暂飙升，等一切稳定后会回落到空闲水平。话虽如此，规划时应参考实际运行时的数字，而不是空闲时的数字。当 CI 在持续运行任务时，应稳定预留 1–2 GB。官方建议的 2 GB 最低配置，是有原因的。
就配置规划而言，这可以直接对应到以下 VPS 档位：
- Forgejo 或 Gitea，基础安装，机器上不运行 CI runner： 1 GB RAM / 1 vCPU is comfortable.
- Forgejo 或 Gitea，且同一台服务器上运行 CI runner： 提升到 4 GB RAM / 2 vCPU，为 runner 留出足够空间。
- OneDev，基础安装： 4 GB RAM is the practical floor. Go to 8 GB if code indexing is heavy or CI is busy.
因此成本差距一点也不细微。一个在 1 GB 服务器上就能轻松运行的精简版 git 服务器，对比一个需要 4 GB 的 OneDev 实例，你的月度 VPS 账单大致会翻倍。对于个人开发者或小团队来说，这就是“基本免费运行”和“一笔你会注意到的支出”之间的差别。而对于每天都要依赖内置 CI 和 PM 功能的大团队来说，这笔投入完全可能是值得的。但这确实是一种取舍：OneDev 的开销就是 JVM，而这笔成本换来的正是 JVM 所运行的那些功能。
Gitea, Forgejo，以及 OneDev 都可以一键部署在 Cloudzy 的应用市场，所以一旦你确定好配置，搭建一个代码托管平台只需几分钟，而不是花一下午折腾 Docker。如果你运行的是 CI runner 或 OneDev 的代码索引功能，多出来的余量就体现在一台 Linux VPS 拥有 root 权限，这样你就可以自行调整 JVM 堆内存和 runner 并发数。
一条与 Cloudzy 相关的特别说明：目前 Marketplace 应用卡片将 Gitea、Forgejo 和 OneDev 的起步配置定为 2 GB RAM。上面提到的 1 GB 建议，适用于没有本地 CI runner 的精简手动安装。如果你是通过 Cloudzy Marketplace 部署的，请遵循应用卡片给出的最低要求，好让操作系统、数据库、软件包更新和后台服务都有喘息空间。
你该选哪个？
你已经看过对比表和各种取舍了，基于我实际运行过这三款工具的经验，下面是我对每种读者画像的直接建议。
选择 Forgejo 如果你想要一个社区治理、带 Actions 风格 CI 的轻量级代码托管平台，并且能接受与 GitHub Actions 之间的一些小差异。这是我对大多数团队的默认推荐。你能获得和 Gitea 一样的核心 git 托管功能，更纯粹的非营利所有权、公开的安全披露、copyleft 许可证，以及三者中最轻的 RAM 占用。如果没有特别的理由去选另外两个，就选这个。
选择 Gitea，如果 你特别想要 MIT 许可证（比 Forgejo 的 GPL-3.0 更宽松）、最大的代码托管社区和生态系统，或者带有 SSO、审计日志和 SLA 的商业 Enterprise 版本。在纯粹的 git 托管功能上，它和 Forgejo 打平，所以你其实是在许可证和所有权偏好之间做选择，如果你的公司需要一个可以联系的厂商提供付费支持，这也是一个考量因素。
选择 OneDev，如果 你想要一次安装就拥有内置项目管理、内置 CI 和代码智能分析，你是从零开始（没有现有的 GitHub Actions 工作流需要迁移），而且你的预算能负担一台 4 GB 以上的服务器。Forgejo 和 OneDev 之间的抉择，说到底就是这个问题：你要买的是一个 git 服务器，还是一个平台？如果答案是“我要的是平台，我不想自己动手接入 CI”，那么 OneDev 的开销就是值得的。
有一个容易被忽视的决策因素：Gitea/Forgejo 系与 OneDev 之间没有迁移路径。数据模型不同，CI 格式不同，schema 也不同。如果你从 Forgejo 起步，后来又决定想用 OneDev（或者反过来），你面对的将是一次基于 API、逐仓库进行的迁移，并且会丢失 CI 历史和项目管理数据。所以，如果 OneDev 的一体化方式对你有一点吸引力，从一开始就用它，要比之后再切换过去便宜得多。在 Gitea 和 Forgejo 之间，迁移是存在的（这就是 迁移路径 已在上文说明），但从轻量级代码托管平台跨越到 OneDev，是一趟单向且有损耗的旅程。现在就把这一点纳入决策考量，而不是等到十八个月之后。
常见问题
Gitea 还是开源的吗？
是的。Gitea 的核心采用 MIT 许可证，可免费自托管，用户和仓库数量不受限制。实际需要注意的问题在于治理模式，而不是源代码开放程度：Gitea 由公司主导，并通过 CommitGo 提供厂商支持的 Enterprise 版本；而 Forgejo 是由社区治理、采用 GPL 许可证的分支，隶属于 Codeberg e.V.。Forgejo 将 Gitea 的商业安排描述为 Open Core； Gitea/CommitGo 对这一说法有异议 并表示开源项目本身并不包含专有代码。所以 Gitea 仍然是开源的，只是它的治理方式与 Forgejo 的社区治理不同。
Forgejo 比 Gitea 更好吗？
就核心 git 托管而言，两者几乎完全一样：Forgejo 从 Gitea 分叉而来，共享同一基础。Forgejo 的不同之处在于治理结构（非营利的 Codeberg e.V.）、许可证（GPL-3.0 copyleft，对比 Gitea 的 MIT）以及安全披露方式（面向所有人公开，对比 Gitea 优先面向 Enterprise 客户的政策）。“更好”取决于这些因素对你是否重要；仅从功能上看，两者不分上下。
OneDev 需要多少 RAM？
OneDev 官方给出的最低要求是 2 GB RAM。在 nodatools.com 的测试中，它空闲时占用约 600 MB，负载下达到约 950 MB。启动过程中，随着 JVM 预热和索引完成，占用可能更高，但如果 CI 正在持续运行，你应该稳定预留 1–2 GB。作为对比，同一测试中 Forgejo 和 Gitea 的空闲占用约为 180–200 MB。
我能从 Gitea 迁移到 OneDev，或者从 OneDev 迁移到 Forgejo 吗？
Gitea/Forgejo 系与 OneDev 之间不存在直接的迁移路径。它们使用不同的数据模型、CI 格式和 schema，因此迁移需要基于 API、逐仓库进行，并且会丢失 CI 和项目管理历史。Gitea 和 Forgejo 之间的迁移是存在的（参见 我们的 Gitea 迁移到 Forgejo 指南），因为它们共享同一血统。
OneDev 支持 GitHub Actions 吗？
不支持。OneDev 使用自己的一套 YAML 方言外加一个 GUI 流水线编辑器，因此为 GitHub、Gitea 或 Forgejo 编写的 workflow 都必须重写才能在其上运行。Gitea Actions 的设计目标是作为直接替代品，因此大多数现有 workflow 无需修改即可运行。Forgejo 的 runner 在实践中也兼容，但并没有被设计成完全镜像 GitHub Actions；在假设完全可移植之前，请查阅 Forgejo 官方文档中记录的不兼容之处。
