Gitea vs Forgejo：自建 Git 平台与 CI 工作流怎么选？

详细比较

别把相近界面当成可直接互换

对只浏览代码和提交拉取请求的人，Gitea 与 Forgejo 的基础体验很接近；对管理员，数据位置、升级节奏、Runner、外部登录与备份方案却是长期成本。如果小团队只需要内部 Git 远端、基本审查和问题追踪，先把现有服务的稳定性及备份能力排在功能数量之前。现有 Gitea 已能满足这些需求时，迁移应由实际问题驱动，例如官方维护路线不合适、确有需要的功能差异，或者团队选择特定项目治理方向。否则一个新平台会带来仓库地址、SSH known hosts、Webhook、部署密钥、CI 令牌和脚本的重新核对。对尚未部署的团队，可同时做一周真实工作流试点，再选择更符合管理员运维能力的一方。

双方官方都提供多种安装路径，选择时不应只比较“启动命令有几行”。容器、二进制与包管理在日志、更新、回退和文件权限上的操作不同。若现有 VPS 已有数据库与反向代理，先检查可用端口、磁盘、备份位置和域名，不要为新 Git 服务改变其他站点配置。若准备在本地小主机运行，电源、磁盘健康与异地备份比首页加载快一点更重要。把安装步骤整理成可重复的配置记录，并确保另一位管理员能从备份启动服务。无法完成恢复演练的“简单安装”只是初次运行简单。

Actions 能否替代现有 CI？

Gitea 官方明确说明 Gitea Actions 的作业由独立 Runner 执行；Forgejo 官方也将 Forgejo Runner 作为独立程序，并提醒其执行工作流代码带来的安全风险。两者都不是打开一个网页开关就得到隔离完好的 CI。若仓库允许来自外部贡献者的拉取请求，要先确定哪些事件可以触发 Runner、工作流能否访问凭据、执行机是否能接触网站数据库或内网。可对内部仓库与公开仓库采用不同 Runner、不同权限和不同网络边界。即便工作流 YAML 看起来相同，也应在沙盒仓库运行构建、测试、发布三类任务，而不是假设语法相似就能直接替换生产流水线。

对使用 GitHub Actions 风格文件的团队，重点核对 action 来源、Runner 标签、容器要求以及机密变量。Forgejo 官方文档说明工作流位于 `.forgejo/workflows`，缺省情况下还可检查 `.github/workflows`；Gitea 官方提供 Actions 的独立说明。目录可被识别不代表每个第三方 action 都有可信来源或完全兼容。尤其部署任务可能持有 SSH 密钥或云端令牌，应检查其访问面，再让新 Runner 接手。若团队已有独立 Jenkins、Woodpecker 或其他 CI，完全可以把代码托管与构建执行分开，不必为了追求“一体化”把不需要的执行能力打开。

版本维护与 LTS 怎么影响选择

Forgejo 官方安装文档描述稳定版与 LTS 发行路径；Gitea 也有自己的发布和升级说明。对管理员来说，关键不是哪一方今天的版本号更高，而是希望多久升级一次、是否愿意在功能发布和稳定维护之间取舍。安全修复、数据库迁移和仓库数据格式变化都有版本条件；写文章当天的“最新”并不能替代部署当天的官方公告。若选择较长维护窗口，也仍需订阅安全公告并安排补丁，而不是把 LTS 理解为无需更新。若团队频繁需要新 CI 或协作功能，则应把测试环境和回滚流程纳入日常维护，否则追新版本只会把集成风险传给业务仓库。

还需核对实际主机和操作系统。某些社区打包与官方二进制的发布时间并不同步。选定某一方后，用正式来源明确下载路径和校验方式，再规划与现有数据库、存储和反向代理的连接。上线前对仓库推送、克隆、LFS、邮件和 Webhook 分别测试；这些环节是否正常不会因为管理页面成功打开就自动成立。若运营的是公共实例，还要关注注册策略、垃圾内容、用户配额及滥用投诉。作为私有团队服务时，账户开通、离职撤权和审计记录可能比开放注册更重要。选择平台也就是选择谁来持续处理这些任务。

数据迁移与 URL 成本

迁移前先清点 Git 仓库本身以外的数据：问题、评论、标签、拉取请求、附件、组织成员、SSH 公钥、用户身份、Webhook、受保护分支、包仓库和 Actions 历史。不同平台的导入功能覆盖范围不一定一致，不能把“一键导入成功”当作逐项保真的证明。Forgejo 官方安装文档专门指向从 Gitea 迁移的说明，也要求核对已有版本兼容性。已有 Gitea 运行时，应先固定源版本、做一致性备份，在隔离环境复刻迁移，再抽样检查复杂仓库与组织权限。没有预演就升级源实例，会使回退更加困难。

仓库 URL 也会传播到开发者电脑、CI 配置、依赖锁文件、容器构建、文档和部署脚本。若切换域名，除网页跳转外还要验证 Git over SSH、HTTPS 克隆和 Webhook 目标是否按预期工作。最好在短时间内让旧地址保留可观察的兼容或明确通知，而不是当天删除所有旧入口。对于不打算换域名的团队，反向代理调整与 SSH 主机密钥也要进入上线检查。迁移结果的判断应基于具体仓库能否完成克隆、推送、审查和发布，而不是仅看数据库表数或导入日志。

备份与恢复要覆盖什么

Gitea 官方备份文档提醒应用数据、数据库与配置都要纳入备份；Forgejo 部署同样不能只保存容器镜像或 Git 仓库目录。数据库承载账户与协作元数据，仓库存储承载代码，附件、LFS 与包数据则可能存于单独目录或对象存储。应为这些材料设计同一时间点的一致性备份，记录版本和配置，并至少在一台独立测试机完成恢复。备份能生成文件不等于恢复时可重建密钥、反向代理、域名和邮件服务。若启用外部对象存储，要把其生命周期与数据库一起考虑。

维护者还应定期检查 Runner 配置和凭据。CI 凭据可能不在应用数据库备份中，而在 Runner 主机或密钥管理系统里；重建 Git 服务后，如果 Runner 自动重新连接却仍有过期的发布密钥，下一次部署会失败。更糟的是从旧备份恢复后复活了已经撤销的账户或令牌。恢复演练需包括用户撤权复核、受保护分支和部署密钥清单。把这些安全与运营项目纳入比较，才能避免只因双方都支持“Git + Actions”就给出武断赢家。

按场景做决定

若团队已经稳定使用 Gitea，且仓库、权限、备份与 Runner 运作正常，先列明迁移能解决的具体痛点，再评估 Forgejo。若新建实例且管理员希望按 Forgejo 官方稳定版或 LTS 节奏维护，并愿意独立管理 Runner，Forgejo 值得试点。若团队已熟悉 Gitea 的升级、插件或 Actions 流程，Gitea 有较低的流程迁移成本。两者都要测试外部集成与恢复。最终决策表应写出所需功能、现有链接数量、允许停机窗口、Runner 信任边界及可接受的维护频率，而不是给平台贴一个普遍“更轻量”或“更安全”的标签。