我自己是在2016年第一次正经搭自建Git的。当时在一个创业团队里GitHub免费私有仓库还没放开公司又不愿意为几个人头掏商业版的钱代码只能靠共享文件夹和聊天软件传来传去传到后来连最新版到底在谁电脑上都说不清楚。被逼到那份上我在一台云主机上装了Gogs从此走上一条回不去的路——自建Git这东西一旦用上你会发现对代码数据的掌控感完全不一样了。到了2025年GitHub免费私有仓库早就放开了Gitee、GitLab.com这些托管平台也都很成熟但自建Git的需求反而没减少。我身边还有很多人坚持自建理由五花八门私有仓库数量限制、代码不能出内网、公司合规要求、团队人数太多买不起托管或者就是想自己的数据自己管。这两年甚至流行起自建全家桶——文件同步、远程桌面、密码管理都往自己服务器上搬——Git自然是里面必不可少的一块。这篇文章就把2025年自建Git的主流方案摊开讲透。我会依次拆解Gitea、Forgejo、GitLab CE、Gogs这几套工具的真实状态包括资源占用、功能边界、维护成本、升级体验再给出一套按团队规模和需求推导的选型流程最后附上完整的部署实操和这几年踩过的坑。无论你是个人开发者想搭一个自己用还是小团队负责人要给同事搭一套可靠的服务都能照着抄。1. 先别急着选工具想清楚你为什么要自建1.1 自建Git解决的四个真实需求每次有人问我自建Git用什么我的第一反应都不是推荐工具而是反问他你先说清楚你要解决什么问题。工具选型脱离了需求就是玄学。过去几年我见过太多人一上来就装GitLab CE结果2核4G的服务器卡到怀疑人生最后又灰溜溜换回Gitea。先说清楚自建Git到底解决什么问题大致就四类。第一个是仓库数量和容量不受平台限制。免费托管平台大多对私有仓库数量和单仓库大小有隐形限制虽然够日常用但一旦搞微服务拆分二三十个仓库堆上去免费额度就开始捉襟见肘。自建的话仓库数量只受磁盘空间限制想建多少建多少。第二个是代码数据不出内网。很多做金融、医疗、企业软件的公司开发环境跟生产环境一样都在隔离网里代码别说放公网连碰都不能往公网碰。这种场景下内网自建Git几乎是唯一解。第三个是不被平台规则牵着走。托管平台的条款、服务状态、账号状态都不是你能控制的。我自己就经历过托管平台突然调整账号规则、某个平台组织账号被误封导致CI大面积挂掉的场景。不是说自建一定更稳但至少出了问题你能自己排查、自己兜底。第四个是深度定制和自动化。自建Git服务一般都有完整的Webhook机制和API你可以把push事件接到自己的IM机器人上可以设置分支保护可以接自己的CI/CD系统。比如我们现在的玩法是开发者push到main分支后Gitea的Webhook自动触发Jenkins构建构建完自动打镜像推到私有仓库这套流程完全跑在自己的基础设施内跟外部平台零依赖。这四个需求对应完全不同的方案选择。如果你只是第一个需求Gitea就够用如果是第二个你还要考虑内网DNS、离线部署甚至要不要彻底断公网如果是第三个维护可靠性、备份方案就变成重点如果是第四个你得重点考察工具的Webhook、API和Actions生态。所以先把需求写下来再来看工具顺序别搞反。1.2 选型前必须回答的五个问题为了把需求具体化我一般会让对方回答下面五个问题。不用特别精确有个大概方向就行但每个问题都会影响选型判断。团队规模多大日常同时在线push的人有几个如果是50人以上还要考虑并发、权限矩阵以及是否需要LDAP、SSO登录对接。除了代码托管你需不需要CI/CD如果需要是只在服务端跑个简单runner还是要完整的流水线、制品库、容器镜像库这台Git服务器的运维由谁负责是专人、是程序员兼职还是根本没人管这直接决定你选轻量好维护还是功能全但繁琐。代码量和二进制文件多不多有没有大量用Git LFS的场景这影响存储规划和是否要上GitLab这类带完整LFS管理的全家桶。你准备怎么部署有没有现成的Docker环境服务器规格是什么如果只有一台512M内存的老机器GitLab基本可以直接出局。这个清单不复杂但真的能帮你少走一大半弯路。下面进入正题把2025年还值得看的几套方案逐个过一遍。2. 2025年还在活跃的方案逐个解剖给你看2.1 Gitea轻量级的绝对主力Gitea是我现在最常用、也最推荐个人和小团队使用的方案。它是用Go写的整个服务就是一个单二进制文件或者一个Docker镜像资源占用非常低。官方文档给的最低要求是2核1G内存但我实测下来512M内存的机器只跑Gitea完全没压力日常内存占用也就三百到五百兆。Gitea的功能覆盖非常全面仓库管理、Issue、Pull Request、Wiki、项目看板、里程碑、Webhook、Git LFS、仓库镜像、组织管理、权限控制这些都有。最关键的是Gitea从1.19版本开始内置了Gitea Actions兼容GitHub Actions的workflow语法配合act_runner就能在自建服务上跑CI/CD流水线。对大多数团队来说这套东西已经够用了。Gitea的迁移工具也做得很好支持从GitHub、GitLab、Gogs等平台一键迁移仓库后台的Migrate功能能把外部仓库连issues带PR一起拉过来。我帮朋友从GitLab CE迁到Gitea时用的就是先建镜像后正式迁移的方式整个过程没丢任何东西。这里需要单独提一下Forgejo。2022年底Gitea发生了治理结构争议社区一部分核心成员fork出了Forgejo由社区基金会运营还被Codeberg采用。到2025年这两个项目都在活跃更新功能上大同小异Gitea版本号还在1.x系列Forgejo已经用7.x、8.x的版本号了。选择的时候不用纠结功能差异更多是看治理偏好。如果你对社区治理这种事比较在意选Forgejo如果你追求更广泛的教程、插件、讨论资源选Gitea。多数人直接选Gitea没毛病。2.2 GitLab CE全家桶但吃配置GitLab CE是很多人一提到自建Git就第一个想到的方案毕竟功能实在太全了代码托管、MR评审、CI/CD、容器镜像库、依赖扫描、安全测试、里程碑、需求管理……基本上一个团队从开发到交付的工具链GitLab一个人全包了。但全能的代价很现实。GitLab基于Ruby on Rails官方给的minimum配置是4核4G内存而我自己的经验是4G只能算能跑多人并发加CI跑起来8G起步才安心。而且它不只是吃内存部署包体积就几个GB升级一次要花不少时间经常遇到大版本升级必须按步骤走、不能跳版本、升级完还要跑migrate这些流程对没有专人运维的团队来说学习成本和维护成本都不低。GitLab CE还有一个比较尴尬的地方它最值钱的CI/CD能力跟自家GitLab Runner深度绑定。如果你只是想要一个代码仓库那为了仓库去扛整套系统属实是杀鸡用牛刀。但反过来如果你的团队确定要一个一体化DevOps平台希望代码、流水线、镜像、文档都在同一个系统里管理而且你有足够的服务器资源和运维人力GitLab CE依然是自建方案里功能最完整的那个。另外提醒一句GitLab的社区版和企业版功能差距挺大很多好用的功能比如某些安全扫描、代码质量门禁是EE独占的。自建CE之前建议先去官网把功能对比表看一遍确认你要的功能没被划到付费区不然装完才发现得买License就尴尬了。2.3 Gogs情怀还在更新停滞Gogs比Gitea还老2014年就出现了是最早让Go语言写Git服务这件事火起来的项目。Gitea最初其实就是从Gogs fork出来的。如果你翻看2016年前后的教程铺天盖地都是Gogs我当时也是从Gogs入门的。但现实是Gogs这几年基本处于低维护状态。核心维护者人力有限很多PR长期挂起功能迭代节奏很慢长时间没有大版本发布。我用Gogs的那个阶段最头疼的是UI过于简陋代码评审功能几乎等于没有很多团队协作场景根本撑不起来。所以我的态度很明确新项目不要再用Gogs了除非你的需求就是一个人、一台小机器、只要能存代码这种极限场景。真遇到这种场景Gitea同样能满足完全没有理由去选一个更新停滞的方案。2.4 其他值得瞄一眼的选手除了上面三个还有几个在特定场景下值得提的方案。如果团队非常看重代码评审流程和严格的提交规范可以考虑Gerrit。它是专门面向代码评审的Git服务很多大型开源项目都用它。但Gerrit的UI和操作习惯跟GitHub、GitLab完全不一样学习曲线陡团队不喜欢折腾的话别碰。如果你的代码量很小、机器配置极低还有一个裸仓库Nginxgitweb的极简方案用git init --bare建裸仓库再用gitweb或cgit提供Web浏览界面。这个方案不提供Issue、MR这些协作功能但胜在轻到极致适合偶尔用一下的个人项目。说句实在话都2025年了能选Gitea就别为难自己。另外还有一类是嵌入式Git服务器比如群晖NAS自带的Git Server本质上就是裸仓库加壳优点是好部署缺点是功能过于简陋。如果手头正好有群晖先拿来应急可以长期用还是建议正经跑一个Gitea。2.5 主流方案核心参数对照对比维度GiteaForgejoGitLab CEGogs开发语言GoGoRuby on RailsGo运行形态单二进制/Docker单二进制/Docker全家桶安装包单二进制/Docker最低内存实测参考512M~1G512M~1G官方4G起实际建议8G512M以下内置CI/CDGitea ActionsForgejo ActionsGitLab CI需Runner无内置容器镜像库有Registry有有无界面体验简洁清晰与Gitea类似功能多、稍显重简陋代码评审PR评论合并同左MR多级审批几乎没有升级维护简单简单较复杂停滞适合规模个人~中型个人~中型中大型/全家桶极小型/备用这张表就是我实践下来的直观结果。接下来按场景推导一下到底该怎么选。3. 按场景选型从个人到中型团队3.1 个人开发者Gitea是默认答案如果你只是一个人用或者加上两三个朋友需求就是有个地方放代码、能看历史、能拉分支那Gitea或Forgejo就是默认答案没有之一。它的部署成本最低一台云主机、一个Docker命令十分钟跑起来资源占用低到可以跟其他服务共用一个台服务器。我自己的服务器上就跑着Gitea、博客和几个小工具互不影响。个人场景我反而建议把能用放在第一位不要为了追求功能去装GitLab CE。我一个朋友就是反面教材觉得GitLab高大上结果服务器只有2G内存每次跑CI都卡到死最后还得换。个人的精力应该放在写代码上不是伺候Git服务器。3.2 小团队3~20人Gitea Actions基本能通吃小团队是我见过最纠结的一群人功能想要全人手又没多少服务器资源也紧。我的建议是Gitea或Forgejo加Gitea Actions这个组合能覆盖你90%以上的需求。Gitea的PR评审、Issue、看板、里程碑足够撑起日常研发流程Webhook能接到各种IM机器人。Gitea Actions能兼容GitHub Actions的workflow写法团队里如果有人熟悉GitHub的用法几乎零学习成本就能在Gitea上写流水线。我帮朋友搭的三四个团队从开发到测试的流水线全部放在Gitea上跑小团队完全够用。唯一要注意的是如果将来需要非常复杂的流水线编排、跨项目触发、细粒度的制品管理Gitea Actions确实比GitLab CI或者Jenkins弱一些。真到了那个阶段要么上一套Jenkins专门做CI要么直接考虑GitLab CE。但别一上来就上重武器。3.3 中型团队20~100人两条路按运维能力定到了这个规模选型就得分叉了。如果你们团队有专人负责基础设施运维而且希望DevOps一体化——代码、CI/CD、镜像、制品都放一个平台——那GitLab CE是合理的。它开箱即用的体验比较完整GitLab CI的流水线功能确实强多人、多项目的权限模型也成熟。如果你们没有专职运维或者工程师们平时已经够忙了我依然推荐Gitea或Forgejo但要把Actions runner、备份、监控补上。几十人的团队用Gitea没问题我实测过在20多人同时并发push的场景下Gitea的响应依然很快。但要注意人员多了之后仓库权限矩阵、组织架构管理、SSO对接这些需求会出现部署时得提前规划好。到了100人以上说实话免费自建方案都有点吃力了——GitLab CE功能上限高但维护负担重Gitea在千仓库级别的权限和审计上不如商业产品精细。这种情况我更建议认真评估商业托管方案或者GitLab EE付费版别硬撑着自建省那点钱。3.4 我见过的几个选型翻车现场说几个真实翻车案例帮大家避坑。案例一某朋友公司一上来就装GitLab CE服务器2核4G两个人开发。结果每隔两周服务器就OOM一次服务跑着跑着没了只能手动重启。换到Gitea之后同一台服务器瞬间安静了还多出大量资源跑别的服务。教训资源不够就别硬扛全家桶。案例二有团队用Gogs用了好几年一直没升级后来想要代码扫描和CI功能发现Gogs完全没有迁移到Gitea又花了不少时间。教训选工具一定要看维护活跃度一个停更的项目你投入越多损失越大。案例三某中型团队选了GitLab CE但没人真正懂它的运维每次升级都折腾到凌晨有一次小版本升级直接把CI全部搞挂。教训GitLab CE的日常维护不是想象中那么免费的人力成本都是隐形成本。这些案例不是我编的都是真实发生过的事。自建Git就这么现实——选的时候省的心维护的时候都要还回去。4. 实操半小时把Gitea跑起来4.1 部署方式怎么选选好了工具接下来就是部署。这里用Gitea举例子因为这是最普适也最省心的选择。部署方式主要三种源码编译、官方二进制、Docker。源码编译基本不推荐除非你要改代码。官方二进制适合在极简机器上直接跑一个文件拷过去、配置好用户和权限就能启动。但我最推荐的是Docker Compose原因有三个环境隔离、升级方便、迁移简单。Docker部署的升级流程基本就是改镜像版本号再up -d回滚也容易二进制部署升级要下载、替换、重启步骤多一点。对于要长期维护的服务Docker Compose能省很多事。Gitea官方文档也提供了现成的Docker Compose示例踩坑最少。4.2 完整部署步骤我直接给一份能用的docker-compose.yml。这份配置我用在好几台服务器上都是这么跑的。version: 3 services: gitea: image: gitea/gitea:latest container_name: gitea restart: unless-stopped environment: USER_UID: 1000 USER_GID: 1000 GITEA__server__DOMAIN: git.example.com GITEA__server__SSH_PORT: 2222 GITEA__server__ROOT_URL: http://git.example.com:3000 GITEA__database__DB_TYPE: sqlite3 volumes: - /data/gitea:/data - /etc/timezone:/etc/timezone:ro - /etc/localtime:/etc/localtime:ro ports: - 3000:3000 - 2222:2222 depends_on: - db db: image: postgres:16 container_name: gitea-db restart: unless-stopped environment: POSTGRES_USER: gitea POSTGRES_PASSWORD: change_me POSTGRES_DB: gitea volumes: - /data/gitea-postgres:/var/lib/postgresql/data说明几个关键点。SSH端口我特意用了2222而不是22因为服务器上本来就有sshd在用22端口直接让Gitea占22会冲突。如果用Docker把2222映射到宿主机客户端SSH地址就要写成ssh://gitgit.example.com:2222/owner/repo.git这也是新手最容易卡住的地方。如果你想用gitgit.example.com:owner/repo.git这种标准写法需要把宿主机22端口让给Gitea并把系统sshd挪到其他端口前提是确定不会把自己锁在门外。数据库这里我用了PostgreSQL因为Gitea官方推荐生产环境别用SQLite。如果只是个人用、仓库不多sqlite3也能跑但多人并发写的时候SQLite偶尔会报database is locked所以小团队及以上我统一建议上PostgreSQL。数据库版本选16没问题Gitea支持得不错。启动之后浏览器打开http://git.example.com:3000会进入Gitea的初始化安装页面。这里重点说一下要填的项站点名称随意仓库根路径默认/data/git/repositories在Docker里指向volume不用改数据库类型选PostgreSQL填上compose里的库名、用户、密码服务器域名填git.example.comSSH端口填2222基础URL填http://git.example.com:3000。如果后面要加HTTPS和域名反代这几项可以先进去再在管理后台改不用太紧张。4.3 配置SSH与HTTPS让push更顺手初始化完之后第一件事就是给用户配SSH公钥。在Gitea的设置 - SSH公钥页面里把本机的~/.ssh/id_ed25519.pub内容粘贴进去就行。如果本机还没生成过密钥先跑一句ssh-keygen -t ed25519 -C youexample.com生成之后把公钥贴到Gitea。克隆仓库时注意用SSH格式git clone ssh://gitgit.example.com:2222/owner/repo.git这里有个常见坑公钥加好了但ssh连不上。排查顺序是先看端口通不通ssh -p 2222 -T gitgit.example.com再看是不是本地用错了私钥指定-i ~/.ssh/id_ed25519再看Gitea日志。大部分情况是端口映射没对或者密钥格式不被认。HTTPS方面最标准的做法是用Nginx反代把git.example.com的443端口代理到容器的3000端口再用Certbot签免费证书。Nginx配置大概长这样server { listen 443 ssl; server_name git.example.com; ssl_certificate /etc/letsencrypt/live/git.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/git.example.com/privkey.pem; 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; } }配好后记得去Gitea管理后台把ROOT_URL改成https://git.example.com不然页面里的克隆链接还会生成http开头的地址。到这里一个基础可用的Gitea就算上线了。接下来聊聊上线之后怎么维护。5. 上线之后维护和避坑才是重头戏5.1 备份必须做对不然等于裸奔自建Git最怕的就是数据丢失。代码这种东西丢了不只是心疼是直接没法干活。所以备份一定得安排上而且要定期验证备份能用别等出事才发现备份是坏的。Gitea官方提供一个备份命令gitea dump它会把配置、数据库、仓库数据、LFS文件全部打成一个zip包。在Docker环境里这样执行docker exec -u git gitea gitea dump --config /data/gitea/conf/app.ini备份文件默认生成在容器内的/data目录下用完后用docker cp拷回宿主机再挪到独立磁盘或者对象存储。注意千万别把备份放在Gitea所在的同一块硬盘上硬盘坏了备份也跟着没了这是最基本的纪律。我自己用的方案是cron定时任务每天凌晨4点执行dump同步到另一台机器和对象存储保留最近30天。恢复的时候先把新机器上的Gitea跑起来把备份zip包解压后覆盖到数据目录重启服务就行。我实际演练过恢复流程基本能半小时恢复完。5.2 升级与迁移宁可慢不能跳Gitea的升级比较简单Docker环境下直接改镜像tag再up -d。但我必须提醒一句大版本升级一定要看官方release notes特别是涉及数据库schema变更的版本升上去就不能随便回滚。我一般会先在一台测试机上把新版本跑起来导入一份生产备份验证没问题再动生产。很多服务升级完就挂的事故都是因为跳过了验证这一步。如果是从Gogs迁移到Gitea那很省事Gitea后台有内置的Gogs迁移API能连仓库带用户一起迁过来。如果是从GitLab CE迁到Gitea没有一键全量迁移的工具我的做法是先直接git clone --mirror所有仓库然后在Gitea里手动建仓库、推入镜像issues和MR历史用Gitea的Migrate功能从GitLab拉取。这个过程有点繁琐所以还是建议项目初期就选对工具省得以后折腾。5.3 常见问题与排查技巧实录整理了我在自建Git维护过程中最常遇到的几个问题做成速查表建议收藏现象可能原因排查思路与解决fatal: not a git repository当前目录不是git仓库确认有没有git init或者cd到正确目录Permission denied (publickey)SSH公钥没配好Gitea设置里检查公钥本地用ssh -p 2222 -T gitgit.example.com测试push时提示输入密码用的是HTTPS方式用个人访问令牌token作为密码别用账号密码Login failed. check api token or gitlab versionGitLab API token权限或版本不匹配检查token的scope确认GitLab版本与客户端要求兼容网页502反代后服务没起来docker ps看容器状态docker logs gitea看错误日志推大文件超时仓库包含超大对象启用Git LFS或者把大文件挪出仓库磁盘满了仓库和LFS把空间占完检查df -h清理旧备份和无效仓库这里面最想单独展开的是SSH端口的问题因为它太经典了。新手十有八九会把宿主机22端口直接映射给Gitea结果跟sshd冲突push失败。更稳妥的姿势是用非标准端口比如2222然后告诉团队成员用ssh://协议地址。如果你特别在意命令好看也可以用Nginx的stream模块做TCP四层转发把公网22转发到Gitea容器的22但那属于进阶玩法新手不建议碰。还有一个细节自建Git服务如果暴露在公网一定要把管理员账号的密码设强开启两步验证千万别用弱口令。我见过有人把Gitea默认账号密码挂在公网上结果被扫描器扫到仓库被清空还留了勒索信息。这种低级错误发生一次心态直接爆炸。5.4 关于Gitea Actions的小实践最后补一个Gitea Actions的实操片段因为这是Gitea相对GitLab最拿得出手的卖点。要跑Actions你需要一个act_runner。官方推荐用Docker方式部署runner只需把它注册到Gitea实例上docker run --name gitea-runner \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /data/act-runner:/data \ -e GITEA_INSTANCE_URLhttp://git.example.com:3000 \ -e GITEA_RUNNER_REGISTRATION_TOKEN官网拿到的_token \ --restart unless-stopped \ gitea/act_runner:latest注册完之后在仓库里放一个.gitea/workflows/ci.yml写法跟GitHub Actions基本一样name: CI on: [push] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Run tests run: go test ./...push上去就会自动触发流水线。这一步走通之后基本就可以抛弃外部CI平台了。我在实际项目中用Gitea Actions跑过前端构建、后端测试、镜像打包总体稳定偶尔遇到actions市场里的第三方action版本旧的问题换一个等价action就行。6. 几句大实话写了这么多最后说几句大实话。自建Git这件事技术门槛真不高真正难的是想清楚自己要什么以及能不能长期维护。我个人折腾下来目前最舒服的组合是一台2核4G的云主机上跑Gitea PostgreSQL act_runner再加Nginx反代和每天自动备份总资源占用常年不到1G内存。这个配置服务过单人项目也服务过二十来人的团队一直很稳。如果要给新上手的人一个建议我会说别追求一步到位先老老实实搭一个Gitea用起来把push、clone、分支管理、备份这些基本盘做到位再慢慢加Actions、加镜像库。等这些都用顺了你自然知道自己的下一个需求在哪儿到时候不管是扩容还是换GitLab都有底气。还有一个我个人的小习惯定期把服务器上所有仓库用git fsck检查一遍完整性再清理一次长期不用的分支和无效备份。这套动作花不了十分钟但能让你永远不用操心仓库突然坏了这种破事。Git服务的价值说到底不是那些花哨的功能而是你随时能push、随时能clone、数据稳稳当当地躺在自己手里的那种安心感。