自建Git服务器选型指南：Gitea与GitLab对比与实战部署

2025年了，还在纠结自建 Git 服务器到底选什么？这个问题我过去几年被问过无数次。很多人一开始觉得 Git 自建很简单，无非是装个软件把仓库放到自己服务器上，可真到选型阶段，打开搜索一看——Gitea、GitLab、Gogs、Gerrit、Sourcehut，再加上各种搭配 CI/CD 的玩法，直接就看懵了。这篇文章我把这些年实际搭建、迁移、踩坑的经验一次讲透，从需求拆解到主流方案横评，再到按场景怎么选、用 Docker 快速搭一套 Gitea、常见故障怎么排，尽量让不同基础的读者都能拿走一份真正可用的选型指南。

1. 为什么都在自建 Git？先想清楚需求

1.1 自建到底解决了什么核心问题

很多人一上来就问“哪个工具好用”，但我的习惯是先问一句：你到底为什么要自建？因为选型方向完全取决于这个答案。

最常见的理由其实是代码资产的所有权。托管平台虽然承诺“数据属于你”，但你的代码最终存储在对方的服务器上，谁能访问、会不会被平台规则影响、服务条款什么时候变，这些都不是你说了算。一旦公司规模大了，或者你做的项目涉及内部业务逻辑、商业机密，把代码放在第三方平台就会有很多顾虑。尤其是很多企业要求代码绝不能出内网，那自建几乎就是唯一选项。

第二个理由是安全合规和内网隔离。金融、医疗、政企类项目经常有明确的控制要求，代码库、流水线、制品都得留在隔离网络里。自建 Git 不只是为了“自己有台服务器”，而是为了配合现有的内网安全策略，统一做漏洞扫描、访问控制、审计记录。

第三个理由是定制化需求。很多团队希望 Git 系统能和内部账号体系打通，比如 LDAP/AD 统一登录、钉钉/企业微信通知、内部任务系统联动。托管平台虽然也开放了不少 API，但很多深度的定制和私有化能力还是会受限制。自建以后，Webhook、API、甚至改源码都完全可控。

把这些原因想清楚以后，你就能理解为什么后面很多方案对比里，我会反复强调“维护成本”和“扩展性”而不是只比功能列表。

1.2 什么情况不建议自建

我也得泼一盆冷水：不是所有人、所有团队都应该自建。

如果你只是一个人写代码，或者团队就三五个人，项目没有特殊合规要求，用 GitHub、Gitee、GitLab.com 这类托管服务其实更省事。人家帮你做了高可用、备份、安全监控，你只需要专注写代码。自建 Git 服务器表面上省了托管费用，但你的隐性成本是：系统升级、数据备份、数据库故障、磁盘空间、网络异常、SSH 权限问题……这些事都得你自己管。

尤其在一些小公司里，负责搭 Git 服务的人可能就是写业务代码的开发者，一不小心就把自己变成了半个运维。我的建议是：在做决定之前，先问自己“未来半年我愿不愿意每周花一点时间去维护它”。如果不愿意，那托管平台可能才是你真正需要的方案。

2. 2025年主流自建Git方案横评

2.1 Gitea 与 Forgejo：轻量级首选

如果让我只能推荐一个方向，那大概率是 Gitea 或者它的社区分支 Forgejo。

先简单说一下背景。Gitea 源自 Gogs 的一个分支，用 Go 语言开发，最大的特点是“单二进制文件”部署。你下载一个可执行文件，跑起来就是一个 Git 服务，不需要额外安装依赖、不需要配置一大堆运行环境。这种轻量特质非常讨好个人和中小团队。

Forgejo 是 2022 年从 Gitea 分支出来的社区治理版本，功能上跟 Gitea 高度相似。两者的区别更多在治理模式上，Forgejo 强调社区中立，Gitea 背后有商业化公司。普通用户如果没有什么特别的组织偏好，用哪一个都行，迁移成本也极低。

Gitea/Forgejo 最打动我的点是资源占用极低。我第一次在一台 1 核 1G 内存的云服务器上部署，跑一个小团队日常使用，内存占用稳定在 300~500 MB。仓库、Issue、PR/MR、里程碑、Webhook、LFS、Wiki 这些基本功能全都有。而且它还内置了 Gitea Actions，基于 act_runner 实现，可以兼容一部分 GitHub Actions 语法，多多少少把 CI/CD 的需求也覆盖了。

它的弱项也很明显：Actions 生态、执行器集群能力、大型仓库性能都不如 GitLab 这种重型平台。如果你有很复杂的 CI/CD 矩阵、大量并发任务，或者需要一套完整 DevOps 平台，Gitea 会有点吃力。

2.2 GitLab CE：一体化平台，但需要运维资源

GitLab CE 是很多中大型团队的首选，因为它不是一个单纯的 Git 托管，而是完整的 DevOps 平台：代码管理、Issue、MR 评审、CI/CD、制品仓库、安全扫描、依赖分析，基本你能想到的都有。

但“全家桶”的代价也很现实。即便是 CE 版本，官方建议配置也要 8GB 内存起步，而且实际部署以后你还会发现它有一堆后台组件：Rails 应用、Sidekiq、Gitaly、PostgreSQL、Prometheus……进程多得让你眼花缭乱。GitLab 比较吃运维经验，升级也不是简单替换二进制，它有固定的 upgrade path，大版本之间不能随意跳，一旦跳版本没按文档走，很可能摔得很疼。

我见过不少小团队一开始冲着 GitLab 的 CI/CD 去，装完才发现团队里没人会维护它。如果你有专职运维或者至少有人愿意长期研究 GitLab，那它确实很强大。但如果你团队不到 20 人，又没有运维资源，用 GitLab CE 之前真的要三思。

2.3 Gogs：老牌轻量方案，但更新太慢

Gogs 是早期 Go 语言实现的轻量 Git 服务，可以说是 Gitea 的“老大哥”。在 2014、2015 年，它是很多自建玩家的第一选择。但后来社区发生分裂，Gitea 分支出去独立演进，Gogs 的更新节奏明显变慢。

现在的 Gogs 基本停留在“能用”的状态：仓库管理、Issue 这些基础功能有，但内置 CI、API 完整性、插件生态跟 Gitea 差了不止一个等级。新项目如果让我选，我不会再推荐 Gogs。除非你手头已经有一套 Gogs 用了很多年，数据迁移成本太高，否则没什么理由在一个还在维护但基本不演进的方案上投入。

2.4 Gerrit：代码评审流程比托管本身更重

Gerrit 跟前面几个不是同一类选手。它本质上是一个围绕代码评审构建的系统，适合对代码审查流程有极高要求的团队。常见的使用方式是开发者把改动推送到 Gerrit 的暂存区，自动触发评审，评审通过后才合入主干。

这种模式在 Android 等大型开源项目里很常见，因为它能做到非常细粒度的权限控制和变更管理。但代价是学习曲线极其陡峭，使用习惯跟 GitHub/GitLab 的 PR 模型差别很大。普通团队贸然上 Gerrit，光是让所有人理解“一个 commit 对应一个 change”就要折腾很久。

我的建议是：除非你的团队已经有严格的代码评审制度和足够的培训预算，否则不要因为“看起来更专业”就选 Gerrit。

2.5 Sourcehut 和其他特殊选择

除了主流方案，还有几个相对小众但值得一提的选项。

Sourcehut 是一个非常极客的 Git 托管服务，也可以自建。它推崇 Unix 哲学，支持邮件列表驱动的协作方式、git send-email、极简界面，功能上很克制。适合那些喜欢命令行和邮件工作流的开发者，但对大多数团队来说，它缺少一套可视化的 PR/MR 体系，上手门槛偏高。

如果你连 Web UI 都不想要，理论上也可以用 Gitolite 在 SSH 上做 git 仓库权限管理，或者干脆就用裸仓库加 SSH。但这种方案在团队协作中几乎不实用，因为 Issue、PR、Code Review 这些现代协作功能都会缺失。

另外，预算充足的团队也可以考虑 GitHub Enterprise Server，它可以私有化部署，体验跟 GitHub.com 高度一致。不过价格不便宜，License 模式也需要评估，对多数团队来说性价比不高。

3. 核心功能对比与选型指标

3.1 一眼看懂的主流方案对比表

先给一张总表，方便快速建立感知：

这张表是方向性参考，不是绝对结论。比如“适合团队规模”那一列，实际还要看仓库数量、并发量、CI 使用频率。Gitea 跑一个超过 50 人的团队也不是不行，但如果你要同时跑大量 CI 任务，单机的性能瓶颈就会很明显。

3.2 容易被忽略的“隐藏”选型指标

功能表只能帮你看个大概，真正影响体验的往往是下面这些没那么显眼的点：

• 统一登录支持：公司有 LDAP/AD 的话，Gitea 和 GitLab 都支持，但配置细节有差异。Gitea 的 LDAP 配置比较轻量，GitLab 的 SAML/LDAP 方案更复杂也更强大。Gogs 虽然也支持 LDAP，但功能比较基础，只能做最简单的登录认证。
• SSH 体验：SSH 是 Git 使用的核心链路。Gitea 和 GitLab 都能管理用户的 SSH 公钥，但如果你用 Docker 部署，一定要处理好 SSH 端口映射，否则 clone/push 会非常头疼。
• Webhook 与 API：如果你想跟内部系统做自动化集成，API 完整度很关键。GitLab 的 API 最完善，Gitea 也比 Gogs 强很多。自动化脚本、机器人、流水线触发都依赖这些接口。
• 分支保护与代码评审：GitLab 的分支保护规则非常细，可以设置不同角色在不同分支上的权限；Gitea 也有分支保护，但粒度没那么细。对合规要求高的团队，这一点差别很大。

3.3 维护成本与升级体验决定了你能走多远

我在选型时最喜欢问一句话：半年后你还会不会愿意升级它？

Gitea/Forgejo 的升级体验是真的爽，替换二进制文件或者重新 docker pull 一个镜像，重启就完成了，很少遇到破坏性变更。GitLab 则完全是另一套玩法，大版本升级要严格按照官方 upgrade path，中间有几次小版本不能跳，升级前还要检查有没有废弃配置。我在操作上见过有人为了省事一口气跨好几个大版本，结果数据库迁移失败，整个系统起不来。

所以，如果团队没有明确的运维人力投入，我更倾向给你推荐轻量方案，因为它的长期维护风险低得多。

4. 实战选型：按场景怎么选最合理

4.1 个人开发者放私人库：稳定省心最重要

个人自建 Git 的核心诉求一般是：我有些私有仓库不想放公司，也不一定信任免费托管平台，想放在自己的服务器或 NAS 上，希望稳定、备份简单、偶尔开个 Issue 记录想法。

这个场景下，Gitea 或者 Forgejo 加 SQLite 就是最优解。SQLite 不需要单独部署数据库服务，备份的时候直接把数据目录打包就行。再加上定时快照或者 gitea dump，个人使用完全够用。

如果你的 NAS 支持 Docker，那就更方便了，直接用镜像把 Gitea 跑起来，映射一个端口就能用。搭配上 Caddy 或者 Nginx 反代，域名和 HTTPS 也都齐活。这套组合我已经用了好几年，几乎没有遇到让我头疼的问题。

我个人在自建服务器上还会频繁用git worktree，因为本地经常需要在多个分支之间并行开发，worktree 能让我把不同分支的代码放到不同目录，避免频繁 stash 和 checkout。配合 Gitea 上的远程仓库，整个工作流干净利落。

4.2 10~30 人中小团队：先想清楚 CI/CD 再做决定

这个规模段是最纠结的。团队说大不大，说小不小，既要考虑协作体验，又要考虑维护成本。

我的建议是：先回答三个问题。第一，你们是不是已经有 Jenkins、Drone、Woodpecker 或其他 CI/CD 工具了？如果有，选 Gitea/Forgejo 做 Git 托管就够了，完全没必要再上 GitLab，避免重复建设。第二，你们是不是希望从代码托管到流水线全在一个平台里？如果是，GitLab 的一体化体验确实好，但也要接受它的资源和维护成本。第三，团队里有没有人能投入运维？没有的话，还是 Gitea 更稳。

如果你选择 Gitea + CI/CD，我比较推荐两条路线。一条是用 Gitea Actions，可以复用一部分 GitHub Actions 习惯；另一条是配 Woodpecker CI，它是一个轻量 CI 系统，和 Gitea 的集成很顺滑，资源占用也比 GitLab CI 小得多。很多人忽略的是，Gitea Actions 的 runner 本身也会占内存，如果你要在同一台机器上跑大量任务，记得给服务器留出余量。

4.3 50 人以上、严格审计或集团管控：考虑 GitLab 或专业方案

当团队规模到了 50 人以上，或者公司有明确的审计、合规要求，事情就变复杂了。这时候你需要的可能不只是代码托管，而是权限模型、审计日志、审批流、制品管理这些企业级能力。

GitLab CE 在这个场景下会比 Gitea 有优势，主要是它的 MR 权限模型和审计能力更成熟。比如你可以设置不同角色在不同项目上的可见性和操作权限，可以把 MR 规则配置得很细，可以查看操作审计日志。当然，如果需要更强的审计、合规能力，可能要考虑 GitLab 的商业版本，或者引入额外的安全审计平台。

如果是那种“代码评审流程必须极其严格”的团队，比如军工、高安全要求或大型嵌入式项目，可以考虑 Gerrit。但前提是团队愿意投入学习成本，并且真正需要这种 Change 级别的评审模型。否则一般公司用 GitLab 或者 Gitea 的 MR 流程已经足够。

另外，集团管控还有一个常见场景：多子公司、多网络区域、多套环境之间同步代码。这时候要注意选择支持镜像仓库和跨区域同步的方案。Gitea 可以配仓库镜像，GitLab 也有相应的功能，但真要做得强，可能还得靠线上平台或者专门的代码中心产品。

4.4 教学培训、竞赛平台内网部署

学校里开软件工程课、组织编程竞赛，经常需要搭一个内网 Git 平台，给几百个学生用。这个场景对性能要求不算高，但对账号管理、项目隔离、快速恢复要求很高。

Gitea/Forgejo 在教育和竞赛场景里非常受欢迎。我见过不少老师用 Gitea 的 Organization 来当班级容器，一个班建一个组织，再往组织里拉学生账号。批量创建账号可以用 API 脚本，也可以在初始化时预置管理员，再手动导入 CSV。因为 Gitea 足够轻，一门课启动了实例，下课了可以停掉，资源占用很低。

如果你用 GitLab，学生规模上来之后，服务器内存和 CPU 会压力很大。除非有专门的运维老师，否则我一般不建议教学场景选 GitLab。

4.5 极简派和“反模式”

也有一小部分人真的不需要 Web UI，也不需要 Issue 系统。他们只是希望有一个内网服务器能让团队成员git clone和git push。这种场景下用纯裸仓库加 Gitolite 是可行的，但我会劝你一句：现在不需要，不意味着三个月后不需要。等团队协作复杂了，你一定会想要在线看代码、发 PR、讨论问题。

所以我的建议是，就算你觉得自己很极简，也先装一个 Gitea 起来，把仓库管起来就好了。用不用 Web 界面是另外一回事，但至少给你留了一条后路。

5. 实操笔记：用 Docker 快速搭建 Gitea 并接入域名访问

5.1 为什么用 Docker 而不是直接跑二进制

Gitea 官方提供了二进制安装方式，理论上也很简单，但我在实际部署时更愿意用 Docker Compose。原因有三个：

第一，隔离性好。二进制直接装在宿主机上，要处理 systemd 服务、用户权限、日志轮转一堆事情；容器方式把这些都隔离在容器里，宿主机干净很多。

第二，升级方便。升级 Gitea 只需要修改镜像版本，重新docker compose up -d，比手动替换二进制还要处理迁移流程舒服得多。

第三，备份更清晰。把数据目录挂载出来以后，备份就是打包整个挂载目录的事，逻辑非常清晰。

5.2 docker-compose 配置参考

下面是一个我实际使用的精简配置。Gitea 搭配 PostgreSQL，适合团队使用场景。如果你只是个人测试，也可以把 database 那段去掉，Gitea 会自动使用 SQLite，但这是可选的。

我用 PostgreSQL 的原因是它比 SQLite 更适合多人并发写，尤其当你有 Webhook、CI 触发、多用户同时操作时，数据库锁问题会少很多。下面的 YAML 可以直接复制使用，但记得修改密码和域名。

version: "3" services: gitea: image: gitea/gitea:1.22 container_name: gitea environment: - USER_UID=1000 - USER_GID=1000 - GITEA__database__DB_TYPE=postgres - GITEA__database__HOST=db:5432 - GITEA__database__NAME=gitea - GITEA__database__USER=gitea - GITEA__database__PASSWD=change_me_db_password - GITEA__server__ROOT_URL=https://git.example.com - GITEA__server__HTTP_PORT=3000 - GITEA__server__SSH_DOMAIN=git.example.com - GITEA__server__SSH_PORT=2222 ports: - "3000:3000" - "2222:22" volumes: - ./gitea:/data - /etc/timezone:/etc/timezone:ro depends_on: - db restart: unless-stopped db: image: postgres:16 container_name: gitea-db environment: - POSTGRES_DB=gitea - POSTGRES_USER=gitea - POSTGRES_PASSWORD=change_me_db_password volumes: - ./postgres:/var/lib/postgresql/data restart: unless-stopped

启动命令很简单，在 docker-compose.yml 所在目录执行：

docker compose up -d

然后打开http://服务器IP:3000，第一次访问会进入安装引导页。这里的数据库连接信息要和上面环境变量保持一致。如果你把GITEA__database__*环境变量已经配置好了，引导页会自动带入一部分值，你只需要确认就可以。

5.3 端口映射和 SSH 的坑

Docker 部署 Gitea 最容易踩坑的是 SSH 端口映射。上面配置里我把宿主机的2222映射到容器的22，因为宿主机自身的 SSH 通常已经占用了22。

这样带来的影响是，用户克隆代码时要使用ssh://git@git.example.com:2222/owner/repo.git这样的地址。所以在页面初始化配置里，SSH_DOMAIN要填你的域名，SSH_PORT要填2222，这样页面生成的 clone 地址才是正确的。

如果你有权限直接用宿主机的22端口，也可以映射22:22，但是要小心宿主机本身的 SSH 会受影响，建议先用非标准端口测试。

5.4 Nginx 反向代理与 HTTPS

我不太喜欢让 Gitea 直接暴露公网，通常会加一层 Nginx 或者 Caddy 反向代理。Nginx 配置的核心是把git.example.com的请求转发到本机的3000端口。

server { listen 80; server_name git.example.com; location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }

然后可以用 acme.sh 或者 certbot 申请免费的 Let’s Encrypt 证书。申请完成以后记得把 443 的 server 配置也加上，并且确认 Gitea 里的ROOT_URL是https://git.example.com而不是 http。很多人在初始化之后发现网页能打开但 clone 地址始终是 http，就是因为ROOT_URL没设置对。

如果你想更省事，可以用 Caddy 替代 Nginx，它的自动 HTTPS 功能非常香，Caddyfile 里只需要一行：

git.example.com { reverse_proxy 127.0.0.1:3000 }

Caddy 会自动申请和管理证书，连 Nginx 配置都省了。

5.5 备份与恢复策略

备份是自建 Git 服务器最重要的事情，没有之一。我的做法是两套备份同时跑：一是云平台或者 NAS 的快照，二是定期跑gitea dump。

Gitea 自带的gitea dump命令会生成一个 zip 文件，里面包含配置、数据库、仓库和 LFS 文件。在容器环境里的执行方式是：

docker exec -u git gitea gitea dump -c /data/gitea/conf/app.ini

生成的 zip 会保存在当前工作目录，恢复的时候把它解压到新的数据目录，再启动容器即可。有一点要注意：gitea dump会把数据库密码也包含在配置文件里，所以 dump 出来的文件要当作敏感数据保管好。

我的建议是，每周至少做一次 dump 备份，并且把备份文件同步到另一台机器或对象存储上。真要遇到服务器硬盘坏掉的场景，一份异地备份能救回你所有代码。

5.6 部署后建议设置的一些配置

Gitea 部署完成后，有几件事我建议尽早处理：

• 关闭开放注册。默认情况下 Gitea 允许任何人注册账号，如果你只给自己团队用，务必在管理后台把Disable Registration打开。
• 开启两步验证。管理员账号一定要绑定 TOTP，避免账号被脱库后直接被登录。
• 设置团队还是项目级权限。建议先建一个顶层 Organization，把仓储和权限放在组织内统一管理，比散落在个人账号下清晰得多。
• 调整 LFS 和上传大小。如果团队会传大文件，记得在配置里打开 LFS，并设置合理的文件大小限制，否则默认的上传限制可能只有几十 MB。

6. 自建后常碰的问题和排查实录

6.1 SSH 连接不上：“Permission denied”

这是 Docker 部署 Gitea 后最常见的问题。现象是ssh -T git@服务器IP -p 2222报权限拒绝，或者干脆 Connection refused。

先确认三件事：第一，SSH 端口映射是否生效，宿主机的 2222 是不是真的转发到了容器 22；第二，Gitea 的SSH_DOMAIN和SSH_PORT配置是否和实际访问方式一致；第三，客户端公钥是否真的加到了 Gitea 账号下。

排查的时候用ssh -vT看详细输出，会显示尝试访问服务器上哪个 authorized_keys。Gitea 容器的 SSHD 逻辑会动态生成 authorized_keys，所以你不用自己去容器里改这个文件。假如你是外部挂载了整个/data目录，且目录权限不对，也可能导致 SSH 读不到 key。遇到这种情况，检查挂载目录的属主是否和容器内USER_UID一致。

6.2 大文件 push 失败：RPC failed

很多团队一开始没上 LFS，等有人把几百 MB 的设计稿或者数据集往仓库里推的时候，就会出现error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413或者fatal: the remote end hung up unexpectedly之类的报错。

解决思路分两层。如果是已经推到仓库的大文件，最好用git lfs migrate把历史文件迁移到 LFS 托管里：

git lfs migrate import --include="*.zip,*.psd,*.bin" --everything

这是 Git LFS 的基础命令，会把指定类型文件重写为 LFS 指针，并生成对应的 LFS 对象。执行完以后要强制推送到远端。建议先用小团队测试，因为这种操作会改写历史，影响所有人。

如果是未来上传大小的限制，一是检查 Nginx 的client_max_body_size，默认只有 1MB，必须调大；二是检查 Gitea 侧的上传尺寸配置和数据卷空间。一个经验是：光调 Git 的http.postBuffer只能解决一部分网络缓冲问题，真正的瓶颈往往在代理层。

6.3 网页慢、操作卡顿

Gitea 和 GitLab 在不同体量下的体验差别很明显。如果你用 Gitea 但网页依然卡，先怀疑服务器内存和 CPU，然后看是不是跑了很多大仓库的 GC 任务，导致 I/O 饱和。

你可以用gitea doctor命令做一次健康诊断，它会检查数据库、仓库完整性、配置一致性等常见指标。如果发现数据库连接占满，考虑是不是太多仓库镜像在同时同步。另外，打开慢也可能是反向代理没有正确设置proxy_buffering，导致大响应体在一次请求里全量传递，积压内存。

6.4 Webhook 不触发

Webhook 是自建 Git 与内部系统集成的关键，但偶尔会出现提交了代码但下游系统没有收到通知的情况。

先检查 Webhook 配置里的 URL、Secret、触发事件是不是勾选对了。如果下游系统用的是内网 IP，而 Gitea 所在环境开了 HTTPS 校验，就需要在 Webhook 设置里允许 “Allow insecure connections”。另外，Gitea 默认的 Webhook 超时比较短，如果下游响应慢，可能会超时。你可以考虑在下游加一个异步接收队列，或者调整超时参数。

我踩过的一个坑是：有团队配置了 Webhook 地址为http://127.0.0.1:8080，这个 127.0.0.1 指的是 Gitea 容器内部的回环地址，而不是外部服务。正确写法应该是宿主机在容器网络里的 IP，或者使用 docker-compose 里的服务名。

6.5 升级失败，服务起不来

不管用哪个方案，升级之前必须备份。这是我反复强调的一点。

Gitea 升级比较平滑，但如果升级后服务起不来，先看启动日志，基本能定位到数据库版本不一致或者配置文件缺字段。通常的做法是停止容器，确认数据目录无损，备份一份 app.ini，再重新启动，让 Gitea 自动跑 migration。如果 migration 卡住，不要反复强杀容器，先去看数据库连接和磁盘空间。

GitLab 升级会复杂得多。跨大版本升级时，建议严格按照官方 upgrade path 来走，中间可能要经过几个中间版本。每上升一个版本，都要检查 Sidekiq 队列、数据库 migration 日志，任何一步异常都别继续往下走，宁可多花时间也不要迷信“直接跳版本”。

7. 最后再分享一点选型私货

我不会告诉你有一个“永远最好”的自建方案，因为工具选型永远要匹配团队现实。但如果你让我今天立刻给一台新服务器选型，大部分情况下我会选择 Gitea 或者 Forgejo，先把备份和升级做好，把ROOT_URL和 SSH 端口配置对，然后安安心心用起来。

GitLab 也不是不好，它是一套真正能承载企业级研发流程的平台，但前提是你有足够的运维资源去养它。最好的工具，不是你功能表上最强大的那个，而是你半年后还愿意持续升级和维护的那个。这一点只有真正踩过坑才会懂。

最后再强调一句：如果你决定自建，请先把备份方案做完，再开始往里推代码。代码一旦丢了，再好的工具都是空谈。希望这篇选型指南能让你少走一点弯路，搭建顺利。