GitLab vs Gitea：代码托管选型指南与踩坑经验

我们组之前在代码托管工具上踩了不少坑从最早的 SVN 迁移到 Git 之后一直在纠结用 GitLab 还是轻量级的 Gitea/Gogs。团队人数从 5 个人涨到了 40 多个人中间换过一次方案所以对这个问题的体会特别深。这篇文章我不打算跟你罗列官方文档上的功能对比表那样太没意思了。我更想从一个实际带团队、每天要处理代码托管、CI/CD、权限管理这些破事的人的角度聊聊这两个方案到底差在哪什么情况下选哪个以及你在部署和使用过程中一定会遇到的那些“坑”。先说结论没有绝对更好的方案只有当前阶段更合适的方案。如果你的团队是 10 人以内、想要极速搭建、维护省心轻量级方案Gitea 或 Gogs绝对够用但如果团队超过 20 人或者对代码安全、权限审计、内网隔离、CI/CD 集成有比较严苛的要求那 GitLab 的完整生态会让你省掉很多麻烦。下面我拆开来说。1. 两个选择的核心逻辑它们根本不是一类东西1.1 GitLab 定位一站式 DevOps 平台GitLab 已经不只是一个 Git 托管工具了它是一个完整的 DevOps 生命周期管理平台——从代码托管、代码审查、Issue 追踪、Wiki到内置的 CI/CD、容器镜像仓库、安全扫描、监控全都有。意味着你可以在一个系统里完成“提交代码 - 跑测试 - 构建镜像 - 部署到服务器 - 验证”的完整闭环。这带来的最大好处是你的团队不需要在 Jenkins、SonarQube、Harbor、Jira 之间来回切换GitLab 自己就能把这些活全部包圆了。尤其是 CI/CD用.gitlab-ci.yml一个文件搞定和代码放一起天然的 GitOps 思路比单独维护一套 Jenkins 舒服太多了。但是功能全的代价就是重。GitLab 是 Ruby on Rails 写的底层依赖 PostgreSQL、Redis、Gitaly、Sidekiq 等一堆组件生产环境部署至少要 4C8G 的机器才能勉强跑得很舒服官方推荐 8C16G。内存动不动就吃 2-3G启动服务慢、吃资源用起来有种“杀鸡用牛刀”的感觉如果只是单纯托管代码这个成本实在是有点高。1.2 轻量级方案Gitea/Gogs定位极简代码托管Gitea 和 Gogs 走的是完全相反的路线——用 Go 语言写的编译完就是一个二进制文件加上配置文件和数据库完事了。内存占用只有几十 MB跑在树莓派或者 1C1G 的云主机上毫无压力。部署过程最快可以在 5 分钟内结束下载二进制、初始化数据库完事。这个量级拿它做个人代码备份、小团队内部协作托管的体验是真心爽。Gitea 是 Gogs 的一个社区分支演化出来的目前活跃度比 Gogs 高得多功能也更丰富内置了 Action、Package Registry所以如果选轻量级方案我建议优先 Gitea。但无论 Gitea 还是 Gogs它就是一个“Git 仓库托管”工具重心在仓库管理和轻量协作CI/CD 这块虽然也在补课但和 GitLab 的成熟度不在一个量级。1.3 两者本质区别定位不同适用场景不同用生活化的类比GitLab 像一个自带食堂、保安、健身房的大型写字楼什么都有但你得付高昂的物业费资源、维护、学习成本。Gitea 像一个共享办公工位桌子和椅子都有核心需求解决得很好茶水间也可能配了但你指望楼里有个完整的健身中心那就为难它了。所以你的团队到底是要一栋“写字楼”还是一个“工位”取决于你的团队规模和业务复杂程度。下面是两个方案的关键差异对照表维度GitLabGitea / Gogs内存占用2GB 起步推荐 8GB几十 MB 到 256MB部署难度高依赖组件多易出问题极低单文件部署CI/CD内置非常成熟基础版Gitea 有 Action但生态较弱代码审查MR 流程完善支持权限分级基础 PR/MR 功能够用但简单资源消耗高极低扩展性企业级支持大规模团队适合小团队/个人维护成本高升级、备份、灾备都要考虑低升级就是一个二进制替换适合规模20 人以上 / 严肃 DevOps1-20 人或轻量使用这个表的背后考验的是你对“团队现状”的判断力——你的痛点到底是缺一个“能放代码的地方”还是缺一套“持续交付的规范体系”。想清楚这一点选型就完成了一大半。2. 资源消耗与部署门槛一次实打实的部署对比2.1 部署 GitLab 的真实体验我最早用 Docker Compose 部署 GitLab本以为一个docker-compose.yml就能搞定结果远远没我想的那么简单。GitLab 官方镜像gitlab/gitlab-ce至少 2GB下载就要等半天起来之后 CPU 一直飙高因为它在后台做初始化。你挂着docker logs看日志一堆初始化任务排队跑等几分钟到十几分钟是很正常的。说一下我当时踩的坑。GitLab 默认端口用的是 80 和 443如果宿主机上已经有 Nginx 或者别的 Web 服务端口冲突就来了。你必须用external_url指定一个别的端口比如http://192.168.1.100:8080然后在容器里映射8080:80和8443:443。这个external_url很关键不只是访问地址的问题你会看到仓库的克隆 URL 都基于它生成。还有那个经典的gitlab.rb配置文件。改完配置文件你以为重启就完事了不你要执行gitlab-ctl reconfigure这个过程会重新生配置并重启一系列内部组件等个几分钟很正常。有次我等得无聊多执行了一次 reconfigure结果和正在跑的升级任务撞车直接报错最后只能进容器手动清理锁文件那次是真的被折腾得不轻。2.2 部署 Gitea 的魔法体验反观 Gitea部署体验可以用“魔法”来形容。我用的 Docker 方式docker-compose.yml里定义两个服务server和db用 SQLite 的话连 db 都可以省。image: gitea/gitea:latest映射端口挂载一个数据卷docker-compose up -d浏览器一打开就能看到安装页面填写仓库名称、数据库信息、管理员账号前后也就是两三分钟。如果不用 Docker甚至你只需要下载那个 100MB 左右的二进制文件扔到/usr/local/bin配 systemd 服务二进制直接跑起来。数据库可以用 SQLite就是一个文件备份直接把目录打包完事。这种简单的体质对中小团队来说太友好了。2.3 资源账单对照GitLab部署 4C8G 服务器跑起来稳定占用空闲内存 2.5GB 左右一有 CI 任务并发跑CPU 和内存曲线直接起飞。官方建议的配置是 8C16G如果你要在上面跑生产级 CI 流水线那这台机器就不能干别的了。Gitea1C1G 的服务器就能带得动 20 人小团队内存常驻大概 100MB 上下你可以把同一台机器上还跑着 Nginx、MySQL 这些别的服务。我见过很多小团队可能就一台 4G 内存的服务器既跑 Nginx 又要挂几个内部系统硬上 GitLab没过多久磁盘 IO 先报警GitLab 自身动不动就 502Unicorn/Gitaly 扛不住最后只能迁移到轻量方案。所以如果你手头资源有限轻量级方案是非常理性的选择。3. 日常使用体感命令、权限和那些你一定会踩的坑3.1 配置 SSH 密钥与 Token不管用哪个方案你要提交代码到远程仓库最常用的方式就是 SSH 密钥。在 GitLab 和 Gitea 里配置 SSH Key 的逻辑基本一样在用户设置里找到 SSH Keys把你本地的~/.ssh/id_rsa.pub内容粘进去保存。但有一点很多新手会踩坑你本机如果之前用过 GitHub已经有了 SSH Key这个 Key 是可以复用的不必重新生成。只要把同一个公钥加到 GitLab/Gitea 的 SSH Keys 设置里就行。如果你发现 SSH 连接不上排查顺序一般是确认公钥是否已经添加到 Web 页面里不是私钥很多新手容易复制只读权限的私钥内容。确认你的 SSH 私钥文件是否存在且权限是 600chmod 600 ~/.ssh/id_rsa。确认仓库地址用的是 SSH 格式gitgitlab.example.com:group/project.git而不是 HTTPS。另外GitLab 的 Token 机制也经常让人一头雾水。新版 GitLab 越来越强调用 Personal Access Token 替代密码——尤其是进行 API 调用或者备用 HTTP 方式时。有些人会遇到“login failed. check api token or gitlab version”这种报错多半是 Token 失效做过密码重置会导致所有 Token 自动失效或者 Token 的 scope 权限不足至少要勾选api、read_repository、write_repository也可能你用高版本 GitLab 配了 v1 API 地址走了已废弃的 v3 通道导致认证失败。弄一个尽量新一点的 Token权限全部先勾上基本能绕过 90% 的登录怪问题。3.2 从 GitLab 拉取代码到本地的正确姿势拉取代码这个操作看起来简单git clone而已但有几个细节在团队内部经常引发混乱。一是分支权限默认每个开发者只有main分支的读权限如果你想限制某人只能看某些 branch 或 tagGitLab 有比较细粒度的 Protected Branches 控制Gitea 也有类似保护分支功能但配置项和组合方式要简单不少。二是 clone 时的用户身份如果一时糊涂用了公司的账号邮箱提交代码历史里就会留下一条错误记录。建议在团队初始化时统一约定提交信息格式比如在 GitLab/Gitea 后台开启“阻止未验证邮箱提交”或“强制 GPG 签名”的规则能省掉后面不少麻烦。三是 GitLab 默认端口问题。很多小团队会用 Docker 映射一个非 80 端口比如 8929那 HTTP clone 地址就会变成http://192.168.1.100:8929/group/project.git没问题。但如果你的防火墙把 8929 封了拉取代码就会直接卡住。检查端口时不要只看 TCP 通不通GitLab 的gitlab.rb里如果设置了nginx[listen_port]和 Docker 端口映射不一致也会出现网页能打开、clone 却连不上的诡异情况。3.3 网页端操作细节Gitea 的 Web 界面非常轻打开项目、看文件、编辑、提交 MR响应都很快。GitLab 的页面功能丰富但有时一个页面加载好多次请求网络稍差一点就会转圈。特别是在内网用 HTTP 明文访问 GitLab 时有些浏览器会拦截敏感操作导致像上传文件、内嵌编辑这样的小功能时不时抽风。关于登录还有一个坑GitLab 有时会遇到“422 登录错误”或者“登录后立刻跳回登录页”。很多时候你在隐身模式或换浏览器能登录是因为缓存了过期的 CSRF Token 或者 cookie 被篡改了。遇到这种情况清掉当前站点的 cookie或者直接隐身模式登录多半能解决。如果你换隐身也登不上再检查是不是设置了外部统一登录LDAP/SSO跳转链路里的回调 URL 没配置正确也会出现反复回到登录页的死循环。3.4 权限模型差异GitLab 的权限模型分得非常细Guest、Reporter、Developer、Maintainer、Owner 五级还可以结合 Group 进行嵌套管理。这在 30 人以上的团队里价值很大——可以精确控制一个测试同学只有 issue 的查看权限开发同学只有自己项目的推送权限管理员才能管理 runner。Gitea 的权限模型要简单得多读、写、管理四个字基本就没有了。它也有 “Team” 概念但颗粒度比 GitLab 要粗。对于 10 人小团队来说这个简单模型完全够用但对需要严格权限审计、不同组不同规范的团队来说你可能就得花额外的精力去手动管理仓库归属而不是靠系统权限分层。4. CI/CD、代码审查与扩展生态这是分水岭4.1 CI/CD 是最大的分水岭如果你的团队要正经跑 CI/CD选 GitLab 的优势就很明显了。在 GitLab 里你在项目根目录放一个.gitlab-ci.yml文件里面定义 stagesbuild、test、deploy 等和 job然后配置一个 GitLab Runner。Runner 可以是独立的服务器或容器也可以是用 Docker 动态创建的。每次代码 push 到分支GitLab 就会自动触发 Runner 跑对应 job。这个过程不需要第三方的 Jenkins、Travis CIGitLab 自己就是控制面核执行面。.gitlab-ci.yml里支持极其丰富的玩法rules条件判断、artifacts产物传递、environment部署环境、needs任务依赖、cache缓存加速。你甚至可以定义多环境staging、production一键部署。这个能力对于中小团队来说是降维打击式的方便——你不需要单独维护一套 CI 系统也不用花大精力学习 Jenkins 的 Pipeline 语法。Gitea 也内置了 Gitea Actions和 GitHub Actions 语法基本一致可以跑简单的 CI 任务比如执行构建命令、跑测试。但它没有真正的 CD 能力——比如把 artifact 推送到 Kubernetes 或者 SSH 到远程服务器执行自动化部署这一块需要你自己写脚本或者集成第三方工具。如果你只是需要“push 之后自动跑一下 go test”Gitea Actions 够用但如果你想搞完整的持续部署流程还是得在 GitLab 和独立 CI 系统之间二选一。4.2 代码审查与 MR 流程代码审查这块GitLab 的 Merge Request 流程非常成熟。你可以设置 approvals审批规则要求代码必须经过至少一个 maintainer 的 approve 才能合入可以配置合并前必须有通过的 CI 任务还可以设置合入分支后自动删除源分支。这些规则组合起来能形成一套比较严苛的团队协作规范。Gitea 的 Pull Request 功能有基础版创建 PR、评论、同意/拒绝合并、冲突检测。但对于 “谁能 approve”、“CI 没过就不能合并”、“合并策略squash/merge/rebase” 这些规则Gitea 的设置要简陋一些。也许这正合小团队的胃口因为规则太多反而拖慢节奏。但当你们开始计较 “谁签的 code review 才算数” 的时候就该往 GitLab 的审批流走了。4.3 插件与集成生态GitLab 的生态包括各种 API、Webhook、Kubernetes 集成、Terraform 支持、安全扫描SAST/DAST、License 合规检查等等。这意味着它在企业级研发流程里能发挥的空间非常大。比如你可以把 GitLab 的groups和 LDAP 组织架构对齐员工入职/离职自动同步权限可以接入 Slack/飞书做通知推送。Gitea 也有 Webhook可以对接飞书、钉钉、Discord、Slack基本的通知能力是有的。但是企业级、体系化的东西——比如统一的审计日志、SCIM 用户管理、合规扫描、全链路 trace 等——就基本为零了。这就是轻量级的代价。5. 备份、升级和日常维护经验5.1 备份策略GitLab 的备份必须用官方工具gitlab-backup create老版本是gitlab-rake gitlab:backup:create它会备份 PostgreSQL 数据库、Git 仓库、附件的文件输出一个 tar 包。另外你还要备份gitlab.rb和/etc/gitlab/gitlab-secrets.json。这个 secrets 文件是加密密钥丢了它备份的数据库也解不开那时候才真是欲哭无泪——有次我 restore 备份时报无权限检查一圈发现是备份目录属主不对chown之后才能正常 restore。所以说备份不只是打包还要定期做一次真实的恢复演练否则备份在那里你也不知道它能不能用。Gitea 的备份就简单多了。用 SQLite 数据库时核心就是备份一个.db文件加custom/目录包含 keys、avatar、附件用gitea dump命令可以生成一个压缩包。你要是用 Docker也可以直接把挂载的 volume 目录整个 tar 走。恢复的时候把文件放回去重启服务即可。这种“复制粘贴式备份”对运维压力小很多。5.2 升级与版本管理GitLab 升级是个技术活。大版本升级不能跳版本要沿着 16.0 - 16.1 - 16.2 这样逐步升每次升完要先跑gitlab-ctl reconfigure和 migration这一步慢了可能要十几分钟。Docker 方式升级就是换 tag、重新 build但底层数据库迁移逻辑还是那个流程。没有时间规划直接跳级升级很容易碰上数据库迁移报错最后只能 restore 备份重来。Gitea 升级就太轻松了。官方提供了gitea dump备份然后新版本二进制替换旧版本跑一次gitea migrate完事。整个过程如果仓库不多一分钟以内就能结束。你要是用 Dockerdocker-compose pull docker-compose up -d两行命令搞定。这对平时忙不过来的小团队来说幸福感不是一个量级的。5.3 磁盘扩容与备份周期还有一点容易被忽视GitLab 的仓库数据量增长非常快尤其是你们开始跑 CI构建产物都放在本机builds目录或 artifacts 里磁盘不够了就各种离奇报错。建议给 GitLab 挂一个独立数据盘并且针对 artifacts 设置过期策略比如 7 天清理否则数据膨胀速度会吓到你。Gitea 因为仓库都走的git协议磁盘占用相对可控但也要留好余量尤其是团队频繁用 LFS大文件存储的话Git 仓库体积也会突飞猛涨。6. 按团队类型给出的选择建议6.1 适合选 GitLab 的团队特征我总结了一下如果你符合下面任意几条选 GitLab 更稳团队规模超过 20 人有正式的技术管理者或 DevOps 角色需要细粒度的权限控制和审批流。你们已经或即将正经跑 CI/CD想让流水线、部署、代码托管在同一个平台闭环。公司有合规要求金融、医疗、政企——需要内网部署、审计日志、SSO/LDAP 集成、数据加密等。你们会频繁做代码审查和分支策略管理希望把质量卡口沉淀在系统规则里。预算充裕愿意在服务器资源和运维人力上投入包括 GitLab Runner 的管理。6.2 适合选 Gitea / Gogs 的团队特征反过来下面这些情况就果断选轻量级方案团队 10 人以下仓库数量个位数到几十个核心诉求就是代码托管和基本协作。服务器资源有限不想为了代码托管专门配一个大机器。没有专职运维开发者自己兼任运维要尽可能降低维护成本。对 CI/CD 需求比较简单或者已经在用 Jenkins / 外部 CIGitLab 内置 CI 的优势发挥不出来。更在意响应速度和部署简单不想面对 GitLab 这种“全家桶式”的复杂度。6.3 做决策前问自己三个问题第一问团队有多少人20 人是分水岭人越多权限和规范越重要轻量方案的“轻”就会变成“不足”。第二问未来两年会走到什么规模如果下个月就要招一波人、走正规军路线那从第一天就上 GitLab 比以后迁移再学习要省力太多。第三问这个平台在你团队里承担什么角色如果你只想当网盘来用放代码就是它最大的意义那轻量级对你就是最优解如果你希望它变成研发流程的枢纽让提交、审查、部署环环相扣那 GitLab 的完整闭环价值就凸显出来了。7. 从轻量级迁移到 GitLab 的路径有朋友问过如果先用 Gitea 跑了一段时间后期要切到 GitLab麻烦吗我的经验是可以顺利迁但要提前规划。Git 仓库迁移的核心其实就两条在 GitLab 上建好对应的项目group/project。在本地把原 remote 地址改成 GitLab 的仓库地址git remote remove origin然后git remote add origin gitgitlab.example.com:group/project.git推送所有分支和 tag。如果想保留所有提交历史和分支用git push --mirror一次搞定。要注意的是Gitea 的评论、Issue、PR 历史不会跟着 Git 仓库走。迁移过去的只是代码上线几年积累的讨论记录需要从 Gitea 导出或者放弃历史有些团队觉得无所谓但做审计的人会很心疼。如果特别在意这些数据可以考虑用 API 脚本把 Issue 和 PR 的标题、描述批量同步过去但附件、评论关联、状态流转的恢复难度很大很多时候不值得硬来。还有一个思路是先上 GitLab然后把 Gitea 当只读归档库保留再逐步把活跃项目迁移到 GitLab。这样过渡会更平滑也不怕旧数据丢失。团队项目中历史文档和数据是重要的参考一次性切换风险较大分阶段迁移会更稳。8. 最后再分享两个小技巧我用了这么长时间发现无论你选哪个方案有两个动作都能帮你少踩很多坑第一先把 Nginx 反向代理落好再开防火墙。不管 GitLab 还是 Gitea最稳定、最省心的访问方式是让它们监听本地 127.0.0.1然后用 Nginx 做 TLS 终端HTTPS80/443 由 Nginx 统一管。这样以后改端口、加域名、接 CDN都不需要动代码托管服务本身的配置。GitLab 尤其如此它自己的 Nginx 组件和宿主机 Nginx 共存时容易搞出一堆问题。第二让管理员定期手动浏览一次页面的“系统维护”或“后台任务”。GitLab 后台有时候会静默列出一些迁移任务或升级提示如果没人看等到下一次发布时很有可能会被奇怪的迁移错误挡在门外。Gitea 相对省心但也不要等到磁盘空间耗尽才想起来看。最后再提一嘴如果你是那种组建十人以下技术团队、想快速把代码托管跑起来的朋友我真心建议先给 Gitea 一个机会。它太轻了你部署完会发现原来代码托管可以这么安静、这么“隐形”不用整天想着照顾它。而当你某天打开后台发现团队规模已经悄然涨到了几十人审批流、流水线、审计记录这些词开始频繁出现在需求里的时候再抬头看看 GitLab 那面旗帜——那才是它该登场的时候。