很多人对自建Git仓库存在一个误解以为买台服务器装个Git、开个共享目录就能搞定。真这么干的人通常在一个月内就会遇到权限混乱、分支被误删、没有Web界面可看、同事问刚才谁改的代码只能挨个问一遍。2025年还考虑Git自建说明你已经有了一定的代码托管需求也意识到云端平台未必适合所有场景。这篇文章就是围绕Git自建用什么工具这个话题把主流方案逐个拆开讲清楚它们适合谁、怎么选、怎么落地。先给结论2025年做Git自建最值得认真考虑的方案是Gitea、GitLab CE、OneDev这三类老牌的Gogs不再推荐新项目使用而Gerrit只适合特定评审流程。接下来我会从真实需求出发把每个方案的资源门槛、功能边界、维护成本和实战经验都过一遍帮你少走弯路。1. 为什么2025年还要自建Git仓库1.1 自建不算开倒车本质是掌控权的取舍很多团队一开始用的是GitHub、Gitee这类托管平台速度快、功能全、开箱即用。但用到某个阶段一定会有几件事让你觉得别扭代码仓库数量多了之后权限模型不够细某些私有项目不想放在第三方平台客户要求代码必须留在内网或者公司网络环境本身就隔离外部平台根本访问不了。Git自建最大的意义就是把代码数据存在哪、谁能访问、怎么走审批这几个核心问题的控制权拿回来。自己搭一套服务代码库、账号体系、备份策略、Webhook通知、CI/CD流水线全部掌握在自己手里。这在有合规要求、需要内网部署、或者团队想要深度定制工作流时是托管平台很难替代的。1.2 先分清一个概念Git客户端和服务端是两回事讨论工具之前要先把概念理清。我们平时说的git clonegit commitgit push这些命令是Git客户端在执行而承载远程仓库、提供HTTP/SSH访问、展示Web页面、管理成员的是Git服务端。很多入门教程里提到的Git小乌龟TortoiseGit、VSCode的Git插件、IDEA里的Git集成都属于客户端工具解决的是怎么提交代码的问题。而自建工具解决的是远程仓库放在哪、怎么管的问题。本文讲的是后者千万别混淆。明确了这一点你才不会在选型时被这个工具支持Windows吗这种客户端层面的问题带偏。1.3 选型前先回答三个问题我见过不少团队在Git自建上翻车根本原因不是工具不好而是没想清楚自己要什么就开始部署。开始对比方案之前建议你先回答三个问题团队规模有多大3个人和30个人对服务端的性能和功能要求完全不是一个量级。代码私密性要求多高是只需要登录认证还是需要细粒度分支权限、合规审计除了托管代码还需要CI/CD吗如果答案是需要那么GitLab和OneDev这类自带流水线的方案会省很多事。这三个问题的答案会直接决定你最终选什么。2. 主流自建方案逐个拆解2.1 GitLab CE功能全家桶但资源账单也很丰满GitLab CE是社区版是目前自建Git方案里功能最完整的一个。它不仅托管Git仓库还自带了CI/CD、容器镜像仓库、依赖扫描、Wiki、Issue管理、里程碑、代码质量检查等一整套DevOps能力。如果你想要一个私有版GitHub的体验GitLab CE基本就是标准答案。但代价也非常明显资源占用高。官方建议最低4GB内存实际生产环境8GB起步才跑得流畅。一台2核4G的云服务器装完GitLab光PostgreSQL、Redis、Sidekiq、Puma这几个进程就能把内存吃干掉大半。配置低了页面加载慢、CI任务排队体验真的会让人崩溃。维护成本也偏高。GitLab的升级机制比较严格通常需要逐版本升级跨大版本跳级很可能触发数据库迁移失败。我见过生产环境从14.x直接升到16.x结果db:migrate卡了一晚上最后只能回滚备份重新走一遍逐级升级。所以如果团队没有专人愿意扛运维选择GitLab前得掂量掂量。2.2 Gitea轻量、省心小团队和个人首选Gitea是Go语言写的单二进制程序安装包本身只有几十MB运行时内存通常几百MB就够。它提供了仓库管理、组织/团队、里程碑、Issue、Pull Request、Webhook、Wiki、文件在线编辑等常用功能还通过内置的Gitea Actions支持CI/CD。对于10人以内的小团队Gitea的体验几乎是零维护。升级就是替换二进制文件或者拉最新的Docker镜像不像GitLab那样要跑一堆数据库迁移。它的Docker Compose部署方式也很成熟数据目录挂载出来备份只要打包整个目录即可。很多个人开发者用一台1核1G的轻量服务器跑Gitea稳得很。还有一个细节Gitea自带仓库迁移功能可以直接从GitHub、GitLab、Gitee等平台一键迁移仓库、Issue和Pull Request换平台时非常方便。这意味着你完全可以从托管平台平滑过渡到自建不需要手动搬运历史数据。2.3 Gogs曾经很火但新项目建议别再选它Gogs和Gitea同源都是Go语言写的轻量方案。Gogs诞生得更早一度是轻量自建的代表。但问题在于Gogs的社区活跃度已经明显下降功能迭代速度跟不上很多现代Git需求比如细粒度权限、内置CI/CD、更好的Pull Request体验都比较欠缺。如果你已经在用Gogs短期不出事就不用折腾迁移但如果是新项目要选型我的建议是直接选Gitea没必要在一个发展趋缓的框架上投入精力。Gitea本来就是从Gogs fork出来的兼容性、社区活力、功能丰富度都更占优势没有理由选老的。2.4 OneDev带自研CI/CD和看板的非主流实力派OneDev是一个相对冷门但值得认真看的方案。它基于Java开发一个应用里就包含了Git仓库管理、Issue跟踪、看板、CI/CD流水线、服务依赖等能力。最吸引人的是它的CI/CD设计不用像GitLab Runner或Gitea Act Runner那样额外部署RunnerOneDev内置了Agent机制可以跨平台构建配置起来比传统CI/CD简单不少。OneDev的资源门槛介于Gitea和GitLab之间官方推荐2GB内存以上。它的界面和交互思路与GitHub/GitLab都不一样团队需要一点适应时间。如果你希望代码托管和CI/CD一体化、又觉得GitLab太重型OneDev值得花时间了解一下。2.5 Gerrit为严格代码评审而生不是通用托管平台Gerrit最核心的定位是代码评审驱动。它的工作流和GitHub的Pull Request模型不同每个change都对应一个独立的refs/changes引用通过严格的pre-commit review、验证插件和权限控制来实现没有评审通过就不能合并。这种机制在AOSP、OpenStack这类需要高度受控代码合入的项目里非常流行。但对于普通业务团队Gerrit的学习曲线偏陡操作习惯和主流平台差异很大很多人第一次用会被它的Change-IdCherry-Pick概念搞晕。结论很明确如果你的团队没有严格的代码评审合规要求远离Gerrit如果有它依然是这个领域最能打的行家。2.6 横向对比快速参考下面这张表是我基于实际部署和维护经验整理的参数上做了适当保守化处理方便你快速筛选方案开发语言最低内存参考核心特色适合规模维护难度GitLab CERuby/Go4GB起8GB更佳全功能DevOps含CI/CD、镜像仓库、审计中大型团队较高升级需逐版本GiteaGo512MB可跑1GB舒适单二进制轻量功能够用升级简单个人/小团队很低GogsGo512MB极简社区发展缓慢老项目存量用户很低但不推荐新选OneDevJava2GB内置CI/CD/看板Jenkins替代性强中小团队中等GerritJava2GB起强评审流、refs引用级权限强合规/大项目较高流程定制成本高3. 按实际需求走选型路径别只看功能列表3.1 个人开发者、10人以内小团队优先考虑Gitea。原因很简单资源消耗低一台云服务器几百MB内存跑起来毫无压力日常所需的Issue、里程碑、Pull Request、Webhook、仓库迁移全都有维护几乎零负担升级替换二进制就行。你甚至可以把它部署在树莓派或Nas上完全不占资源。如果你只是想要一个自己的GitHub来放私有项目选Gitea基本不会错。它唯一的短板是CI/CD不如GitLab原生但配合Gitea Actions或外部Drone也能完成大部分需求。3.2 中大型团队需要完整DevOps闭环这种情况说实话没有比GitLab CE更省心的全家桶。它把代码、Issue、CI/CD、镜像仓库、代码质量整合在同一个界面里团队成员不需要来回切换系统。尤其是已经有运维经验、能接受一定维护成本的团队GitLab带来的统一体验很值。团队如果用了KubernetesGitLab CE还支持直接在集群上注册Runner滚动部署、环境管理都做得很成熟。不过要提前想好硬件预算别用1核2G的机器硬扛同时要建立版本升级的规范化流程定期做备份确保不会在升级时翻车。3.3 需要一个轻量代码托管自带流水线的组合如果嫌GitLab太重又觉得Gitea自带CI/CD还不够OneDev是一个性价比很高的中间态。它在应用内集成了类似Jenkins的流水线支持Docker/Kubernetes构建环境还能用服务依赖建模微服务之间的构建顺序。这套设计对不想单独维护一个Jenkins的团队非常友好。我自己曾经把一套JenkinsGitLab的架构整体迁移到OneDev上构建链路反而更清晰了因为代码、流水线、部署配置在同一个系统里权限模型也能统一管理。3.4 硬件与人力成本是隐形决策项很多人选型时只比功能列表忽略了两个隐形变量硬件成本和运维人力。我给团队做技术方案时有一个很朴素的判断公式如果硬件成本超过100元/月或者团队成员没人愿意持续维护那就应该优先考虑轻方案。Gitea把成本压得很低一台轻量服务器足够跑很久。GitLab则意味着你要为内存、存储、备份、升级留出更多预算和人力。别被免费社区版迷惑免费的是软件贵的是伺候它的时间和机器。4. 部署与日常维护那些我踩过、你最好别再踩的坑4.1 部署方式怎么选Docker Compose是最优解无论选Gitea还是GitLab我都建议优先使用Docker Compose部署。它能把应用、数据库、Redis、SSH端口映射统一写进一个docker-compose.yml迁移服务器时只要把整个目录搬过去一条命令就能恢复服务。下面是一个Gitea的docker-compose示例实际部署时可直接改端口和存储路径version: 3 services: gitea: image: gitea/gitea:latest container_name: gitea environment: - USER_UID1000 - USER_GID1000 - GITEA__server__DOMAINgit.example.com - GITEA__server__SSH_PORT2222 - GITEA__server__ROOT_URLhttp://git.example.com/ restart: always volumes: - ./gitea:/data - /etc/timezone:/etc/timezone:ro - /etc/localtime:/etc/localtime:ro ports: - 3000:3000 - 2222:22注意SSH端口映射这个细节。Gitea容器内的SSH默认走22端口但宿主机22端口往往被系统SSH占用所以通常会映射成2222。此时仓库的SSH clone地址会带上端口号例如ssh://gitgit.example.com:2222/owner/repo.git要让团队提前知道不然第一天就有一堆人问为什么clone不下来。GitLab的Docker Compose也是一样的思路但内存开销更大建议部署前先给服务器预留至少8GB可用内存。可以在官方文档里找到通用示例结合自己的域名、SSL证书一起配置。4.2 GitLab初始配置的三个隐藏坑GitLab第一次部署完后最容易踩的坑有三个。第一个坑是root密码。新版GitLab首次访问时系统会生成一个临时密码存在容器里的/etc/gitlab/initial_root_password文件中24小时后自动删除。很多人等了一天再去登录发现密码文件没了只能进容器用gitlab-rails runner重置。正确做法是首次登录前先把密码拿出来保存好登录后立刻改掉。第二个坑是SMTP邮件配置。GitLab很多功能依赖邮件比如注册确认、找回密码、Merge Request通知。如果SMTP没配好你会遇到邀请成员后对方一直收不到邮件的尴尬局面。建议在初始配置阶段就把SMTP设置写入gitlab.rb避免后续反复改配置重启。第三个坑是外部URL配置。external_url必须填实际访问地址如果配成http://localhost那么所有通过域名访问的克隆地址都会变成http://localhost/...看起来莫名其妙。这个配置和HTTPS证书、反向代理息息相关要提前规划好。4.3 Gitea升级与备份简单归简单细节别漏Gitea的备份官方推荐用gitea dump命令它会生成一个包含配置、仓库、数据库、附件、LFS的zip包。我一般建议备份和升级分开操作先执行gitea dump再替换新版本二进制启动后检查仓库列表和Issue是否正常。如果你是Docker部署备份就更容易——把挂载的./gitea数据目录完整打包或同步到异地。注意Gitea的SSH密钥、Webhooks、OAuth应用信息都存在数据库中所以数据库备份和文件备份必须同步不能只拷仓库目录。升级Gitea同样要注意changelog。虽然它没有GitLab那种严格的逐版本限制但从大版本跨度升级时仍建议先看官方升级说明避免某些配置在新版本里被废弃后报错。我升级过一次从1.19跳到1.21中间有些app.ini里的配置项失效对照文档逐一调整才恢复正常。4.4 SSH、HTTPS与Token认证的实战选择自建Git服务启动后团队访问远程仓库一般有SSH和HTTPS两种方式。SSH体验最好配好公钥后push/pull全程免密是大多数团队的默认选择HTTPS则适合临时使用比如在别人机器上快速clone这时候推荐配置Personal Access Token而不是直接用账号密码避免泄露明文密码。在配置SSH时有一个细节容易被忽略Git服务器管理的是每个用户的公钥而客户端需要把私钥加入到ssh-agent中否则每次连接都要输密码。Windows用户可以运行下面两条命令eval $(ssh-agent -s) ssh-add ~/.ssh/id_ed25519此外公司内网如果通过Nginx反向代理Git服务要注意保留SSH的独立端口转发因为HTTP反向代理只转发443/80不会自动转发SSH端口。很多人配置好Nginx后HTTPS能打开页面但SSH clone一直连接失败原因就在这里。4.5 备份策略别偷懒要有手贱可回滚的能力不管选什么方案备份都不能只做仓库目录。一个完整的Git服务备份必须包含Git仓库数据、配置文件、数据库、SSH密钥、Webhook配置、OAuth应用密钥。很多人以为Git历史都在仓库里丢了也不怕实际上你丢的是Issue、PR、成员权限、Webhook这些周边数据恢复起来非常麻烦。我的经验是每天做一次全量备份并保留最近7天版本。备份文件同步到另一个机房或对象存储避免服务器一旦故障备份跟着一起消失。真到了需要恢复的那天你会发现这个动作救了很多次命。5. 想自建得像样这些配套能力不能少5.1 Webhook让代码事件变成自动化引擎自建Git服务一个很大的优势是Webhook完全可控。你可以把push、PR、Issue事件推送到自家CI、聊天机器人、发布平台或者工单系统。Gitea的Webhook配置路径是仓库设置→Web 钩子→添加WebhookGitLab则在设置→Webhooks。收到事件后常见做法是给CI系统发一个JSON请求触发流水线或者给团队IM机器人发通知。举个例子一个简单的push事件payload里会包含仓库名、分支名、提交者、提交hashCI可以据此精准构建。我对新团队的建议是先把Webhook接到IM通知让大家感受到代码提交后群里有动态这样团队对自建平台的认可度会高很多后续再逐步把自动部署、自动构建接进来。5.2 CI/CD选自带还是外接看你的容忍度选Gitea的话可以用Gitea Actions这是GitHub Actions近似的体验通过.gitea/workflows/*.yml文件定义流水线需要额外部署act_runner。选GitLab的话用.gitlab-ci.ymlRunner可以在Kubernetes、Docker、裸机任意环境运行。选择的关键在于维护成本是否可控。我见过有些团队把CI配置得很华丽但半年后没有人维护流水线天天红灯。与其这样不如一开始把CI限定在构建测试镜像打包三层保证简单可靠。等团队有专门人员再逐步加部署、加扫描。5.3 分支保护与权限模型别等到事故再后悔自建平台默认的权限模型往往偏宽松。仓库管理员如果没开分支保护任何开发者都能直接push到master/main一次误操作就能搞挂生产环境分支。正确做法是在Gitea的分支设置或GitLab的Protected Branches里把主干分支设为仅允许维护者/管理员推送所有更改必须通过Pull Request合并。再配合要求评审通过后才能合并的规则既能保证代码质量也能减少谁动了主分支这类扯皮。权限上建议按仓库→团队→成员三级模型管理而不是把成员一个个直接加到仓库里。团队在不同项目间流转时改一次团队权限就能全局生效省心很多。5.4 别把.git目录暴露在Nginx之下最后说一个很常见但容易被忽略的安全隐患如果自建平台是通过Nginx或静态文件服务器对外提供文件访问一定要确保.git目录不能被浏览器直接下载。攻击者只要在URL后面拼上/.git/config或/.git/HEAD就能下载到Git元数据进一步还原源代码。这在安全圈里叫Git目录泄露很多内网测试、源码泄露事件都和这个配置疏漏有关。Nginx里可以加上下面这一段location ~ /\.git { deny all; }即使是正规的Git服务本身Gitea、GitLab他们的Web服务已经处理了.git路径的访问逻辑一般不存在这个问题。但如果你在Nginx层面把静态目录直接指到了某个裸仓库目录上那就非常危险一定要检查。6. 最后分享一点我自己的实际体会做了这么多年Git自建我最大的感受是工具选型决定下限流程管理决定上限。Gitea和GitLab都是经过大量验证的成熟方案选哪个都不会错真正让团队体验拉开差距的是Webhook打通、分支保护、备份恢复这些看不见的功课。如果你现在还在纠结我的建议是先拿一台1核2G的服务器把Gitea跑起来把团队代码迁过去用两周体验一下仓库管理、PR协作、Webhook通知带来的完整感。等团队到了30人、真正需要CI/CD一体化的时候再上GitLab也不迟。自建Git本来就是一个持续演进的工程先小步快跑再逐步加码比一开始就上一套庞然大物要稳得多。