Gitea：一个用 Go 写的自托管开发服务，能否替代 GitHub？

它解决什么问题，为谁而做

Gitea 的目标是提供一个自托管的、一站式的软件开发服务。它的 README 明确写着要成为“最简单、最快、最无痛”的搭建方式。这意味着它瞄准的是那些不想把代码放在 GitHub 或 GitLab 公有云上的团队，原因可能是隐私、合规，或者只是想拥有完全的数据控制权。它包含 Git 托管、代码管理、代码审查、问题跟踪、项目看板、Wiki、团队协作、包注册表，以及可以复用 GitHub Actions 的 CI/CD。换句话说，一个 Gitea 实例可以替代多个独立工具，比如单独的问题跟踪器、Wiki 和 CI 系统。它特别适合中小型团队，因为这类团队往往缺少运维资源来搭建和维护复杂的工具链。Gitea 用 Go 编写，因此可以运行在 Go 支持的所有平台和架构上，包括 Linux、macOS、FreeBSD/OpenBSD 和 Windows，覆盖 x86、amd64、ARM、RISC-V 64 和 PowerPC。这种跨平台特性降低了部署门槛，尤其是当你的服务器是 ARM 架构的树莓派或低功耗设备时。

核心机制：单二进制与模块化服务

Gitea 的架构可以从它的构建和运行方式中看出来。它编译成一个单独的二进制文件，运行 `./gitea web` 就启动服务器，`./gitea help` 列出所有命令。这种单二进制设计意味着没有复杂的依赖安装，拷贝文件即可运行。但要注意，它并不是一个微服务架构，所有功能，包括 Git 托管、Web 界面、API、包注册表和 CI/CD 调度，都集成在一个进程里。这种设计的好处是部署简单，资源占用低，坏处是水平扩展时只能通过增加实例并共享数据库和存储来实现，而且某个功能模块的问题可能影响整个实例。CI/CD 部分通过 Gitea Actions 实现，它兼容 GitHub Actions，这意味着你可以复用现有的 GitHub Actions 工作流文件，但实际执行需要单独的 runner，即官方提供的 action runner 项目。数据流方面，用户通过 Git 协议或 Web 界面与 Gitea 交互，Gitea 负责管理仓库存储、处理 Webhook、调度任务，并通过配置的数据库（通常是 SQLite 或 MySQL）来存储元数据。

部署与配置：从二进制到容器

根据 README，部署方式有两种主要路径。一是直接下载官方二进制，构建后运行 `./gitea web`，但这需要你先从源码构建，文档要求阅读 docs/build-setup.md 和 docs/build-source.md。二是使用官方 Docker 镜像，这是文档推荐的方式，支持 docker 和 podman 等容器工具。对于快速体验，可以访问 demo.gitea.com，或者使用免费服务 gitea.com（但仓库数量有限）。配置方面，动态配置选项可以在管理后台的配置部分修改，而静态配置项则需要编辑 `app.ini` 文件并重启实例。`app.ini` 是 Gitea 的核心配置文件，示例文件在 custom/conf/app.example.ini，配置参考在文档的 config-cheat-sheet。例如，你需要设置数据库类型、HTTP 端口、基础 URL 等。重启实例是修改静态配置后的必需步骤，这意味着配置变更会有短暂的停机，对于生产环境需要规划维护窗口。

CI/CD 兼容性：GitHub Actions 的复用与边界

Gitea Actions 是它最大的卖点之一，因为它声称可以复用 GitHub Actions。这意味着你可以把现成的 GitHub Actions 工作流文件放到仓库的 .github/workflows 目录，理论上无需修改就能运行。但兼容性不是绝对的，文档没有说明所有细节，实际使用中可能会遇到某些 action 的版本或私有 action 的访问问题。另一个关键点是，Gitea Actions 需要单独的 runner 来执行任务，这个 runner 是官方项目 gitea/runner，你需要自己部署和管理这些 runner。这与 GitHub 托管的 runner 不同，你需要考虑 runner 的可用性、网络连接和资源分配。对于 CI/CD 需求复杂的团队，这种自托管 runner 的模式增加了运维负担，但同时也让你完全控制构建环境，这在某些安全敏感的场景下是优势。如果团队主要依赖 GitHub 生态的现成 action，迁移到 Gitea 前应测试关键工作流。

包注册表与协作功能

除了 Git 托管和 CI/CD，Gitea 还集成了包注册表，可以托管软件包，具体支持哪些格式 README 没有列出，但可以推断它覆盖常见的语言包，比如 npm、PyPI、Maven 等。这对团队来说意味着可以自建私有包源，不再依赖外部服务。团队协作功能包括代码审查、问题跟踪、项目看板、Wiki，这些在 README 中被列为标准功能。代码审查支持 Pull Request 流程，这是开源协作的核心。问题跟踪和看板提供了基本的项目管理能力，但相比专业工具如 Jira，功能可能有限。Wiki 可以用于团队文档，但如果你需要高级权限控制或复杂文档结构，可能需要额外工具。整体上，Gitea 的目标是“all-in-one”，但每个功能都是基础版，深度不如专业工具。对于需要复杂工作流或精细权限管理的团队，可能需要在 Gitea 之外补充其他工具。

局限性与不适合的场景

Gitea 的一个明显局限是它的单体架构，所有功能集中在一个进程中。当用户量或仓库数量增长时，性能可能成为瓶颈，虽然 Go 的性能不错，但单体应用的水平扩展能力有限。另一个局限是 CI/CD 的 runner 需要自托管，这增加了基础设施的复杂度，而且 Gitea Actions 对 GitHub Actions 的兼容性并非 100%，某些高级特性可能不支持。此外，Gitea 的文档分散在多个地方，比如 README 提到 docs 网站、build-setup.md、development.md 等，对于新用户来说，找到特定配置可能需要多次跳转。安全性方面，README 要求漏洞报告发送到 security@gitea.io，并提到在 CHANGELOG.md 中搜索 SECURITY 关键词可以找到安全补丁，但补丁的发布周期没有说明。对于需要企业级支持、SLA 保障或合规认证（如 SOC2）的组织，Gitea 的社区支持模式可能不够，他们应该考虑商业版本或 Gitea Cloud。

替代方案与差异

最直接的替代方案是 GitLab，它同样提供自托管的 Git 托管、CI/CD、包注册表等功能。但 GitLab 的架构更重，通常需要更多的内存和 CPU，而且其 CI/CD 使用 .gitlab-ci.yml 配置，与 GitHub Actions 不兼容。如果你已经熟悉 GitHub Actions，Gitea 的兼容性是一个优势，而 GitLab 则需要学习新的 CI 语法。另一个替代是 Gogs，它是 Gitea 的前身，但 Gitea 已经独立发展，功能更丰富，社区更活跃。Gogs 更轻量，但功能较少，适合极简需求。如果你不想自托管，GitHub 或 GitLab 的 SaaS 服务是选择，但你就失去了数据控制权。Gitea 的定位是轻量、易部署，而 GitLab 则更强大但更复杂。选择取决于你的团队是偏好简单还是需要深度功能。

编辑结论

Gitea 适合那些想要完全控制自己代码托管和开发流程的中小型团队、个人开发者，以及出于合规或隐私原因不能使用公有云服务的组织。它不适合需要企业级 SLA、高级安全审计或复杂插件生态的大型企业，这些用户应评估 GitLab 或 Gitea Cloud 的商业支持。在采用前，应先验证你的 CI/CD 工作流能否迁移到 Gitea Actions，因为其兼容 GitHub Actions 但并非完全一致。同时，检查 app.ini 中静态配置项的调整方式，因为修改后需要重启实例。具体来说，部署前应测试官方 Docker 镜像，并阅读 docs/build-setup.md 以确认你的架构是否支持。最后，确认 MIT 许可证对你的分发或修改没有限制，并留意安全补丁的发布位置，即 CHANGELOG.md 中的 SECURITY 关键词。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes