Gitea vs GitLab vs GitHub：轻量自托管代码托管平台的架构对比与选型指南

1. 一个直觉GitHub和GitLab已经很成熟为什么Gitea还能活得很好不少第一次接触 Gitea 的人都会问同一个问题GitHub 不是早就成了开源托管的代名词了吗GitLab 也几乎成了私有化代码托管的默认选项Gitea 到底有什么存在价值这个问题如果只看功能列表确实会得出三者在做同一件事的结论。但你要是真正动手部署过或者在一个小团队里负责过代码基础设施就会很快意识到GitHub、GitLab、Gitea 虽然都叫代码托管平台本质上完全不是同一个物种。GitHub 的核心是社区。它围绕公开仓库构建了全球最大的开发者协作网络Fork、Star、Pull Request、Issue 这些概念被它用到了极致你在上面能获得的不仅仅是代码托管还有开源项目的流量、技术讨论、人才曝光。GitLab 的核心是DevOps 一体化它把自己定位成一个从代码托管、CI/CD、安全扫描、部署发布全流程覆盖的企业级平台一个软件仓库里塞下了你可能需要的所有研发工具链。而 Gitea 的核心是轻量自托管它想解决的是最朴素的问题我能不能用很低的成本、很低的维护负担在完全可控的环境里跑起一个好用的 Git 服务正因如此Gitea 才能在两个巨头都已经很成熟的情况下依然活得非常滋润。它服务的用户群体非常清楚自己要什么——不需要社区的庞大流量不需要几十上百个企业级功能需要的是一个开箱即用、省资源、好维护、数据完全掌握在自己手里的代码托管工具。这篇文章我会把 Gitea 从技术架构、功能边界、实际部署三个维度讲透然后把它和 GitLab、GitHub 放在同一个台面上做一次硬核对比最后给出一套可以落地的选型思路。1.1 一眼看懂三个平台的定位差异要理解 Gitea 的价值先看一个很直观的对比维度GiteaGitLabGitHub核心定位轻量级自托管 Git 服务一体化 DevOps 平台全球开源协作社区 SaaS部署方式单二进制 / DockerOmnibus / Helm组件较多不用自己部署典型用户个人开发者、小团队、内网环境中大型企业、重视 DevOps 闭环的团队开源项目、公开协作、SaaS 用户运维成本极低较高需要持续关注依赖组件零运维推荐硬件1 核 CPU 512MB 内存可跑官方建议 4GB 内存起步无需关注数据控制权完全自主完全自主自托管版在 GitHub 手中从上表能看出来GitHub 和 GitLab 其实不完全是 Gitea 的竞争对手更像是两种极端路线GitHub 把协作体验和生态做到极致GitLab 把企业级 DevOps 链路做到极致而 Gitea 走的是第三条路线——你有一台哪怕很旧的服务器或者 NAS也能获得一个不错的代码托管体验。1.2 什么样的用户画像最需要 Gitea我接触过的 Gitea 用户大致是这几类个人开发者想存私有仓库又不想被平台绑定付不起或不想付 GitHub/GitLab 私有仓库的费用三五人的小团队需要一个内部代码库统一管理项目但不想专门配一台高配服务器去跑 GitLab公司需要在内网环境做代码托管数据完全不能出内网还有一大批 NAS 玩家顺手在设备和飞牛这样的 NAS 系统里装一个 Gitea省心又省资源。这些场景有一个共同特征团队规模不大仓库数量有限但对可控性和成本极其敏感。GitLab 当然也能满足这些需求但它的组件架构决定了它需要更强劲的机器、更频繁的维护。Gitea 在这种场景下几乎就是为需求定制的。2. 轻量级的底气来自哪里Gitea 的架构与技术设计要说清楚 Gitea 为什么能做到这么轻必须从它的技术底座谈起。Gitea 是一个用 Go 语言编写的 Git 托管服务。Go 语言的编译特性让 Gitea 最终可以打包成单一可执行文件整个程序跑起来只依赖一个进程这在部署和运维上带来的优势是巨大的。2.1 单一二进制的部署优势用过 GitLab Omnibus 的人应该都有印象安装包几百 MB安装完以后系统里多了 PostgreSQL、Redis、Sidekiq、Gitaly、Puma 等一系列组件每个组件都有自己的日志、配置和升级节奏。GitLab 不是不好而是它确实是一个平台不是一个软件。Gitea 反过来官方发布的压缩包解压后通常只有一个可执行文件加上一个空配置目录就能跑起来。你甚至可以把它拷到一台没有图形界面的 Linux 服务器上直接./gitea web启动然后浏览器打开 3000 端口就能完成安装。如果你想用 Docker官方镜像同样非常小拉取速度快启动后占用的资源也远小于 GitLab 全家桶。2.2 数据库与存储默认 SQLite 就够用Gitea 支持 SQLite、PostgreSQL、MySQL/MariaDB 三种数据库。对于绝大多数小规模部署官方默认的 SQLite 完全够用。SQLite 是一个文件型数据库所有数据落在一个文件里备份时直接把整个数据目录拷走就行不需要单独去考虑数据库的备份和恢复。这一点对非专业运维的用户非常友好。很多人在自己的 NAS 或者一台小服务器上装 Gitea根本不想也没必要去维护一个独立的数据库服务。SQLite 模式下整个 Gitea 的数据就是仓库目录 app.ini 配置文件 SQLite 数据库文件逻辑非常清晰。只有当团队规模明显变大、并发写入压力上来以后才需要考虑切换到 PostgreSQL。从我实际经验来看几十人规模的团队日常使用SQLite 并不会成为瓶颈。真到了需要切换数据库的规模Gitea 官方也提供了对应的迁移工具和文档不用太担心被绑定。2.3 资源占用到底低到什么程度很多人对轻量没有概念我给一组直观数据一台 512MB 内存的轻量云服务器装完系统后剩余可用内存可能只有 400MB 左右。GitLab 在这种机器上基本是无法正常运行的内存不够会导致各种组件 OOM。而 Gitea 在这种配置下能流畅运行实测进程常驻内存通常在 200MB 上下CPU 在空闲时几乎可以忽略不计。官方文档给的是最低 1 核 CPU 256MB 内存的推荐配置但实际用下来系统本身还要占用一部分内存所以我的建议是至少 512MB。这个配置标准比 GitLab 官方建议的4GB 内存起步整整低了一个数量级。对预算敏感的个人和团队来说这意味着可以用一台很便宜的机器甚至一台树莓派、一个软路由、一台 NAS就能跑起一个正式的代码托管服务。2.4 和 GitLab 技术栈的直观对比GitLab 采用 Ruby on Rails 框架围绕它需要配套 PostgreSQL 数据库、Redis 缓存、Sidekiq 后台任务队列、Gitaly 存储服务再加上 Nginx 做反向代理。这一整套组件各有各的生命周期和配置方式升级时必须要考虑组件之间的兼容性。Gitea 直接把这一切压缩到了一个 Go 进程里。Go 语言天生适合高并发网络服务静态编译没有运行时依赖部署就是拷贝文件。这种架构选择决定了 Gitea 的运维体验和 GitLab 完全不同升级只需要替换二进制文件或者拉取新镜像配置集中在 app.ini 一个文件里。这不是说 Gitea 比 GitLab 更先进只是在轻量自托管这条目标上Gitea 的架构选择和目标高度一致。GitLab 组件多是因为它承载的功能确实多两者面对的需求不同架构自然分道扬镳。3. 硬核对比Gitea、GitLab、GitHub 的功能边界说完了架构进入最关键的功能对比。这里要注意对比不是为了证明谁比谁强而是为了让你看清楚每个平台的边界在哪里。3.1 核心开发协作功能对比先把最常见的功能拉一张表方便快速对照功能GiteaGitLabGitHub私有仓库不限免费版有限制免费版不限私有仓库Pull Request / Merge Request支持支持叫 Merge Request支持Issue 跟踪支持支持支持子 Issue支持Wiki支持支持支持代码审查基础版完整版完整版CI/CD内置 Gitea Actions内置功能完整GitHub Actions容器镜像仓库内置 Registry内置GHCR制品仓库基础支持完整支持支持项目里程碑支持支持支持时间线 / 甘特图无支持Projects 有视图代码搜索基础完整完整Web IDE无编辑文件可用完整Codespaces安全扫描无 / 依赖第三方完整基础 / 依赖应用从功能完整度看GitLab 和 GitHub 明显压过 Gitea。但要注意这张表里的很多功能对小团队来说可能一年都用不上一次。Gitea 覆盖的代码托管 PR/MR Issue Wiki CI/CD Registry这一套组合拳对绝大多数中小团队已经足够日常使用了。3.2 CI/CD 能力的差异与选择CI/CD 是这三个平台差异最大的地方值得单独说。GitHub Actions 是当下最流行的 CI/CD 系统生态极其丰富Marketplace 里有无数现成 Action语法被大量开发者熟悉。它的劣势是只能在 GitHub 上用私有仓库在免费的 usage 额度内够用超过就要付费。GitLab CI 是最早把 CI/CD 深度集成进代码托管平台的方案之一使用.gitlab-ci.yml定义流水线内置 Kubernetes 集成、环境部署、安全扫描等企业级能力。在一个平台搞定从代码到发布这条路上GitLab 做得最彻底。Gitea 从 1.19 版本开始内置了 Gitea Actions整体设计兼容 GitHub Actions 的语法和工作流概念只要你写过 GitHub Actions几乎可以直接把.github/workflows下的配置改成 Gitea 对应的.gitea/workflows来用。它通过act_runner作为运行器可以部署在独立机器上也可以和 Gitea 服务部署在一起。我实际用下来的感觉是Gitea Actions 对常规的构建、测试、打包、发布流程完全够用比如前端项目npm run build后把产物上传到服务器或者后端项目编译出二进制然后通过 SSH 部署到目标机器都没问题。它和 GitHub Actions 的兼容性也在持续提升但毕竟生态起步晚一些冷门 Action 可能需要手动适配。如果你需要的不是够用而是企业级流水线编排比如复杂的并行任务矩阵、细粒度的权限控制、审计日志、多环境部署策略那 GitLab CI 仍然是最稳妥的选择。3.3 团队管理和权限模型GitHub 的组织结构是 Organization Team仓库挂到 Team 下面通过 Team 的权限继承来管理访问。GitLab 引入了 Group 和 Subgroup 的层级结构一个顶级 Group 下面可以无限嵌套子 Group权限可以逐级继承很适合大型组织按部门、项目、模块分层管理。Gitea 在这块做得比较简单有 Organization也可以建 Team但整体模型比较扁平没有 GitLab 那样的多级 Subgroup。对大多数十人以内的团队Gitea 的权限模型够用但如果你要管理几十个仓库、按小组细分权限、做严格的代码保护策略Gitea 会显得力不从心。代码保护方面三个平台都支持分支保护规则可以限制谁可以直接 push 到主分支、必须通过 PR/MR 合并。Gitea 在这块的基础能力是具备的但在精细化程度上不及 GitLab 和 GitHub比如强制线性历史、状态检查的细粒度配置等Gitea 的支持相对简单。3.4 迁移、镜像与第三方生态Gitea 有一个很好用的功能就是仓库迁移。它可以直接从 GitHub、GitLab、Gitea、SVN 等来源导入仓库连 Issues、PR、Wiki、标签、里程碑这些附属数据都能一并带过来。这对于想从 GitHub/GitLab 迁移过来的团队来说省了大量手工搬运的工作。Webhook 和 API 方面Gitea 提供了完整的 REST API 和 Webhook 支持Jenkins、钉钉、企业微信、飞书、Slack 等工具的集成都有现成方案。Gitea 的 API 设计思路接近 GitHub 的 REST 风格从 GitHub 迁移过来后很多脚本逻辑改改 URL 就能复用。GitLab 的生态在于 DevOps 工具的完整闭环GitHub 的生态在于海量的第三方 App 和 Action。Gitea 的生态虽然比不上这两家但够用的 API 标准的 Webhook 兼容 Actions 的 CI这一套组合已经覆盖了日常开发中绝大多数的自动化和集成需求。4. 选型不是哪个强选哪个而是合适比强大更重要在实际项目里我见过不少人一开始咬牙上了 GitLab结果服务器配置跟不上日常卡顿、构建排队最后还是换回了 Gitea。也见过团队在 Gitea 上跑了一段时间以后随着业务复杂度上升主动迁到 GitLab 的。选型这种事最忌讳的就是一步到位的思维——工具永远应该跟着需求走。4.1 我建议你选 Gitea 的场景如果你符合下面的多数情况Gitea 会是一个非常舒服的选择团队规模在 10 人以内或者个人开发者主要诉求是私有代码托管需要 GitHub/GitLab 的替代品服务器资源有限不想为了代码托管单独配一台高配机器需要完全控制数据代码必须存在自己的服务器或 NAS 上希望部署和日常维护尽量简单不想整天盯着组件升级CI/CD 需求以常规的构建、测试、部署为主不需要太复杂的企业级流水线。在这些场景下Gitea 的轻量和简单是实打实的优势。我自己在一台 2 核 4GB 的旧台式机上跑的 Gitea上面挂了一个 6 人团队的日常代码运行一年多基本没怎么管过系统更新时顺手把容器升级一下就行。4.2 我劝你别选 Gitea 的场景反过来如果你的需求里有下面这些特征Gitea 可能不是最优选团队规模几十人以上需要严格的权限层级、审计日志、合规管理需要内置的完整 DevOps 链路比如流水线里的自动安全扫描、依赖漏洞检测、Kubernetes 原生部署需要私有化的 GitHub Codespaces 或 GitLab Web IDE 这类云开发环境对高可用有明确要求比如必须有完整的集群故障转移方案需要用专业的项目管理视图如 Epic、里程碑甘特图、需求追踪矩阵来管理研发流程。这些场景下GitLab 的完整性和 GitHub 的生态会更有价值。尤其是中大型企业的研发团队GitLab 的 Group Subgroup 层级结构、细粒度的角色权限、完整的审计能力和 Gitea 的扁平模型完全不是一个量级。4.3 三个问题帮你快速做决定遇到拿不准的情况我会用三个问题来快速定位这个平台需要支撑多少人同时使用我或团队愿意为维护它付出多少时间除了代码托管我还需要它提供什么不可替代的能力如果人数不超过 20、愿意花在维护上的时间每周不超过 1 小时、除了代码托管没有特别复杂的 DevOps 诉求那 Gitea 大概率就是你的答案。如果人数超过 50或者团队正在推行严格的流程规范GitLab 会更值得投入。5. 部署 Gitea 最容易踩的坑Docker、SSH 与域名问题从网络上的搜索热度也能看出来真正拦住用户的不是 Gitea 的功能理解而是部署落地时的具体配置问题。docker 部署、SSH 设置、clone 地址不对这几个是高频踩坑点。我把实际操作中遇到的问题整理一下直接给方案。5.1 Docker 部署的基础配置用 Docker 跑 Gitea 是目前最常见的方式官方镜像gitea/gitea维护得比较勤直接使用即可。一个最简的启动命令是这样docker run -d \ --namegitea \ --restartalways \ -p 3000:3000 \ -p 2222:22 \ -v /data/gitea:/data \ gitea/gitea:latest这里有一个关键设计宿主机 3000 端口对容器 3000 是 Web 访问端口宿主机 2222 对容器 22 是 SSH 端口。为什么要单独映射一个非 22 端口因为宿主机上很可能已经跑着系统自带 SSH 了直接用 22 会冲突。映射成 2222 之后SSH clone 的地址会是gityour-server:2222/用户名/仓库名.git。首次启动后浏览器打开http://你的IP:3000进入安装页面。这里要注意把管理员账号设置好因为 Gitea 只有在安装界面才有创建管理员的操作入口装完之后再想在文档里找到入口会比较绕。5.2 容器环境 SSH 的端口陷阱很多人在容器部署后遇到一个经典问题Web 界面显示仓库的 SSH 克隆地址是git服务器IP:用户名/仓库名.git没有端口号复制下来 clone 的时候连接失败。原因很简单Gitea 在安装时记录的 SSH 端口还是默认的 22而你的实际映射端口是 2222。解决办法有两个一种是在安装页面里把 SSH 服务器端口 字段直接填成映射后的宿主机端口也就是 2222这样界面显示的克隆地址就会带上端口。另一种是部署完成后修改app.ini里的SSH_PORT配置[server] SSH_PORT 2222改完以后重启容器。这里很多人会犯的第二个错误是重启之后依然显示旧地址。原因通常是浏览器缓存或者 Gitea 的系统配置里保存的还是旧值建议直接走一遍站点管理 - 配置页面确认当前生效值。5.3 clone 地址变成容器 ID 或内网 IP 怎么办另外一个高频问题我在搜索热词里也看到了类似场景clone 地址总是显示成容器 ID 或者机器的内网 IP不是自己想要的域名。这个问题的根源通常不在 Gitea而在ROOT_URL配置。假设你准备让团队通过https://git.example.com访问 Gitea并且前面用 Nginx 做了反代那么安装时或者在app.ini里必须把站点地址配置为完整的对外地址[server] DOMAIN git.example.com ROOT_URL https://git.example.com/配置了ROOT_URL之后Web 界面里展示的 HTTP clone 地址和 SSH clone 地址才会基于这个域名生成而不是显示容器的 ID 或随机端口。这个问题和 GitLab 里clone with HTTP 怎么也带不出域名的坑是同一类问题本质都是外部访问地址没有正确告诉应用。用 Nginx 反代的时候还要额外注意 WebSocket 和 HTTP 头转发配置。如果反代之后 Web 界面能打开但某些操作卡住多半是缺少了正确的 Host 头传递。5.4 LFS、备份与升级的注意事项Gitea 支持 Git LFS大文件存储用于托管二进制文件、设计稿、模型文件等不适合直接放 Git 仓库的内容。需要在app.ini中开启[server] LFS_START_SERVER true开启之后LFS 文件默认存在数据目录下的lfs文件夹里。注意LFS 文件不属于 Git 仓库的普通对象备份时如果只拷贝了裸仓库会把 LFS 文件漏掉。备份方面Gitea 自带的命令是gitea dump它会帮你把配置文件、数据库、仓库数据、LFS 文件、附件等打包成一个 zip 文件。Docker 部署时用docker exec执行即可docker exec -u git gitea gitea dump -c /data/gitea/conf/app.ini升级也很简单Docker 方式通常是拉新镜像、重建容器。但有个建议升级前一定先看官方发布的 Breaking Changes 清单。Gitea 的升级偶尔会有配置项废弃或默认行为调整提前确认能避免升级完突然无法登录、Webhook 不触发这类问题。5.5 和 Jenkins 等工具联动时的 Webhook 细节Gitea 的 Webhook 类型支持 Gitea、Gogs、Slack、Discord、钉钉、企业微信、飞书、通用 JSON 等。如果你用 Jenkins 做持续集成推荐用通用 JSON Webhook 配合 Jenkins 的 Generic Webhook Trigger 插件。具体配置流程是在 Gitea 仓库的设置 - Webhooks - 添加 Webhook里URL 填 Jenkins 的接口地址例如http://jenkins:8080/generic-webhook-trigger/invoke触发事件选择仓库推送和标签推送Content Type 选application/json。Jenkins 那边用 Generic Webhook Trigger 插件解析 Gitea 发过来的 JSON提取出仓库名、分支名再映射到构建参数里。这里有个容易踩的坑Gitea 发送的 Webhook 请求默认没有携带任何认证信息如果 Jenkins 开在公网必须有额外的防护否则任何人都能通过这个地址触发你的构建。建议用 Token 参数做简单校验或者让 Jenkins 只在内网监听。6. 从 GitHub 或 GitLab 迁移到 Gitea 的个人经验最后聊一个很多人关心的话题手头已经有 GitHub 或 GitLab 的仓库了想迁到 Gitea 怎么操作这部分我实际踩过坑说点经验。Gitea 的创建仓库 - 迁移仓库功能可以导入 GitHub、GitLab、Gitea 以及其他 Git 服务上的仓库。导入时可以选择连同 Issues、Pull Requests、Wiki、标签、里程碑一起迁移。从 GitLab 迁移到 Gitea 时建议先把源仓库的导入权限检查好尤其是私有仓库需要在 API Token 里给足权限否则会出现仓库成功导入但 Issues 全丢的情况。迁移顺序上我的建议是先在一台测试机上完成全量导入确认数据没问题之后再把正式服务器上的 Gitea 跑起来。然后让团队成员先 clone 新的 Gitea 地址推一个测试分支验证权限和 Webhook最后再改 Jenkins 或 CI 的仓库地址。整个切换过程里最容易被忽略的是本地 Git 远端地址的更新。几十个人的团队每个人本地都指向旧地址切换后一个个通知很麻烦。可以写一个小脚本统一把本地origin替换成新地址能省下大量沟通成本。从个人的实际感受来说从 GitLab 迁到 Gitea 之后最直观的变化就是省心。原来 GitLab 每月都要操心备份、升级和内存占用换到 Gitea 之后基本做到了部署完就忘的状态。Gitea 也确实有一些细活不如两个大平台比如代码搜索的响应速度、超大仓库的浏览体验但日常使用中并不会有明显痛点。如果你现在的需求正好卡在想要一个私有、可控、又不想为运维投入太多的位置Gitea 值得直接上手试一下。装一台机器拉个镜像跑起来把自己的几个仓库导进去用两天比看一百篇对比文章都更有判断力。