Gitea：开源自托管 Git 服务，轻量到树莓派都能跑的 GitHub 平替
它到底是什么
Gitea 是一个用 Go 编写的自托管软件研发平台，目标很直白：提供最简单、最快速、最省心的一站式 DevOps 服务。它把 Git 托管、代码管理、代码审查、Issue 跟踪、项目看板、Wiki、团队协作、包仓库以及 CI/CD（可复用 GitHub Actions 语法）这些能力塞进了同一个二进制里。
> “The goal of Gitea is to make the easiest, fastest, and most painless way of setting up a self-hosted all-in-one software development service.”
整个项目采用 MIT 协议开源，仓库放在 GitHub（go-gitea/gitea），官方文档站点是 docs.gitea.com。对想避坑商业 SaaS、又想拿一套完整研发工具的人来说，Gitea 是目前社区里呼声最高的选择之一。
核心功能：从 Git 托管到 CI/CD
Gitea 的功能覆盖面相当宽，已经不是单纯的”代码托管工具”。以下几类能力在主线版本中都已内置：
- Git 仓库管理：支持 SSH 和 HTTPS 协议访问，仓库级权限、标签（Tag）、Release、Wiki 一应俱全。
- Issue 跟踪：标签（Label）、里程碑（Milestone）、指派、关联提交/PR，覆盖日常需求与缺陷管理。
- Pull Request 与代码评审：行内评论、Diff 视图、Code Owner 审查要求、状态检查（Status Checks）等都已具备。
- Gitea Actions：与 GitHub Actions 高度兼容的 CI/CD 模块，绝大多数
.github/workflows/下的 YAML 可以直接搬迁使用。 - 组织与团队权限：Org / Team 模型允许按仓库、按分支设置读写权限。
- 项目看板：轻量的 Kanban 视图，把 Issue 和 PR 拖到不同列里跟踪进度。
- 包仓库（Package Registry）：支持常见格式的包发布，构建产物可直接托管。
再加上官方提供的 tea CLI、go-sdk 以及 act_runner，日常使用和二次开发都有现成工具链。
轻量到极致：单二进制 + 跨平台
Gitea 最被人称道的就是它的”轻”。
> “As Gitea is written in Go, it works across all the platforms and architectures that are supported by Go, including Linux, macOS, FreeBSD/OpenBSD and Windows on x86, amd64, ARM, RISC-V 64 and PowerPC architectures.”
实际部署中它体现为几个特点：
- 单文件部署：构建产物就是一个可执行二进制，扔到服务器上
chmod +x就能跑，不需要额外的运行时。 - 资源占用低：相比 GitLab 这种”全家桶”，Gitea 在 1 核 1GB 的小机器上也能流畅运行，社区里把它跑在树莓派上的案例很多。
- 架构兼容广：除了常见的 x86_64 服务器，ARM、RISC-V 64、PowerPC 这些架构都在官方支持范围内。
换句话说，只要你的设备能跑 Go 程序，就能跑 Gitea。这一点对个人开发者、边缘设备玩家、以及想给家庭实验室搭一套代码托管的人来说非常友好。
部署方式：Docker 是最省事的路径
官方提供了完整的部署方式选项，下面是常见的几条路径：
1. 容器化部署（推荐）
使用 Docker 或 Podman 直接拉镜像是最常见的玩法：
docker pull gitea/gitea:latest
docker run -d --name gitea \
-p 3000:3000 -p 2222:22 \
-v /path/to/data:/data \
-v /path/to/config:/etc/gitea \
-v /etc/timezone:/etc/timezone:ro \
-v /etc/localtime:/etc/localtime:ro \
gitea/gitea:latest3000 是 Web 端口，2222 是 SSH 端口，数据和配置分别挂到宿主机，方便备份和迁移。
2. 二进制部署
从 GitHub Releases 下载对应平台的二进制，解压后直接运行：
./gitea web # 启动 Web 服务
./gitea help # 查看所有可用子命令3. 源码构建
如果想自己改代码或者折腾定制化功能，可以参考仓库里的 docs/build-source.md。前置条件在 docs/build-setup.md 里有详细说明，开发流程则看 docs/development.md。
4. 一键上云
不想自己维护服务器，官方还有 cloud.gitea.com 提供托管试用，以及 demo.gitea.com 的演示环境，gitea.com 提供免费但仓库数量受限的服务。
Gitea vs Forgejo vs GitLab：该怎么选
社区里讨论最多的就是 Gitea 与它的几个”近亲”的关系，简单梳理一下：
| 项目 | 定位 | 资源占用 | CI/CD | 适合场景 |
|---|---|---|---|---|
| Gitea | 官方主线项目，MIT 协议 | 极低，单二进制 | 内置 Actions（兼容 GitHub Actions 语法） | 个人、小团队、想轻量自托管的人 |
| Forgejo | Gitea 的社区分叉，强调”软分叉”治理模式 | 与 Gitea 接近 | 同样兼容 GitHub Actions 语法 | 希望由社区而非单一组织主导的人 |
| GitLab | 全功能重型 DevOps 平台 | 较高，推荐 4GB+ 内存 | 内置 CI/CD（独立语法） | 大型企业、需要完整合规与安全特性的场景 |
| GitHub / Gitea.com | SaaS 托管 | 免运维 | GitHub Actions | 不想自托管、要即刻上手的人 |
关于 Forgejo：它是 Gitea 的一次社区分叉，由一部分核心贡献者发起，目标是摆脱单一公司的影响、保证项目长期中立。两者在功能层面差别不大，生态也基本互通。选择哪个更多是治理理念的偏好。
关于 GitLab：GitLab 是”全家桶式”的 DevOps 平台，从代码托管到安全扫描、内置 K8s 集成、CD 流水线都覆盖。代价是吃资源、重运维，并且部分企业级特性需要付费版。Gitea 的定位正好相反——只做最常用的事，并且做得足够轻。
适合谁用
结合上面的特性，Gitea 比较适合这几类人和场景：
- 个人开发者：想给自己写的小项目找一个干净的备份点，避免依赖单一商业平台。
- 小团队/工作室：需要一个带权限管理、Issue 看板、PR 流程的工具，但又不想养一台重负载的服务器。
- 教育/科研场景：实验室里给课题组搭一个内部代码托管服务，对资源占用敏感。
- 从 GitHub 迁移的用户：Gitea Actions 兼容 GitHub Actions 语法，Issue、PR、Wiki 都能导入，迁移成本低。
对于已经习惯 GitHub Actions 工作流的开发者，把仓库搬到 Gitea 后几乎不用改 YAML。
周边生态与社区
围绕 Gitea 已经形成了比较完整的外围工具链：
- tea：官方命令行工具，可以在终端里管理 Issue、PR、Release。
- go-sdk：官方 Go 语言 SDK，方便做二次开发或集成。
- act_runner：Gitea Actions 的执行器，类似于 GitHub 的 runner。
- awesome-gitea：社区维护的相关项目列表，包括各种插件、主题、第三方 SDK 等。
社区沟通渠道以 Discord 和官方 Discourse 论坛为主；翻译通过 Crowdin 协作，已经覆盖了包括简体中文和繁體中文在内的多种语言。
配置与运维要点
刚装好 Gitea 时，通常会碰到两个配置文件：
- 动态配置：可以在管理员后台的”配置”页直接修改并热生效。
- 静态配置：需要编辑
app.ini文件并重启实例。完整可选项参考仓库里的custom/conf/app.example.ini以及配置速查表。
安全补丁一般会在 Release Log 或 CHANGELOG 里用 SECURITY 关键字标注，订阅其发布通知能比较快地跟进。如果发现了未公开的漏洞，建议私下联系 [email protected]，而不是直接提公开 Issue。
小结性建议
如果你的需求是”自托管、轻量、对 GitHub 兼容、能跑在小机器上”，Gitea 是目前最值得优先试的方案之一；如果更看重”重型全功能、企业合规”，则需要重新评估 GitLab 或商业平台。具体版本、依赖和最新功能特性建议以 docs.gitea.com 和 GitHub 仓库的 README 为准。
评论(0)