这些年问我“有没有国产 GitLab”的人越来越多了而且问法五花八门有人是被网络卡到崩溃有人是被版本和合规逼的还有人是纯粹想搞清楚 Gitee 和极狐 GitLab 这俩到底有什么区别。说实话这个问题放在两年前还没有标准答案但现在答案已经很明确了Gitee 和极狐 GitLab 都具有“国产替代”的属性但它们的出身、产品形态、功能边界和适用人群完全不同。这篇文章就围绕这三个方案——Gitee、极狐 GitLab以及顺带总要提一嘴的自建 GitLab——把功能、部署、实操和踩坑经验一次说清楚。1. 为什么大家都在问“国产 GitLab”三种方案的出身与定位1.1 先厘清一个概念你需要的到底是“国产”还是“国内可用”很多人一上来就问“有没有国产 GitLab”但实际上心里想的是几件不同的事一是 GitLab 官方 SaaS 在国内访问太慢、时不时超时想要一个访问顺畅的替代二是企业出于数据合规和自主可控要求必须把代码托管到国内平台或自己的服务器三是个人开发者就想找个类似 GitLab 的界面和协作体验但不想折腾海外服务。这三种诉求看起来都是“国产 GitLab”可对应方案完全不一样。如果只是要“国内访问快、注册就能用”Gitee 就够了如果是“要 GitLab 的原版体验又要能私有化部署、满足合规”那极狐 GitLab 是正路如果团队有运维能力、想完全自主掌控那么自己在服务器上部署 GitLab CE 依然是常见选项。先说清楚这个问题后面选型才不会跑偏。1.2 极狐 GitLab根正苗红的 GitLab 中国分支极狐 GitLab很多人第一次听会以为是某个国产轮子其实它的背景很有意思这是 GitLab Inc. 和中国资本合资成立的公司产品核心就是 GitLab 的企业版EE然后针对中国市场做了本地化。你可以把它理解成“GitLab 官方派来中国参赛的选手”。它的优势很直观功能上与 GitLab Enterprise Edition 保持高度一致那些在 GitLab.com 上熟悉的功能——代码托管、Merge Request、Code Review、GitLab CI/CD、Epics、License Compliance、安全扫描等等基本都是原生能力不用重新学。同时它是国内运营主体、提供中文文档和技术支持也可以部署在自有服务器上很多客户会选择把它部署到国产化环境里。如果你要的“替代品”必须保持 GitLab 的操作习惯和功能深度极狐 GitLab 是最省事的答案。1.3 Gitee最接地气的国内老牌托管平台Gitee码云是开源中国推出的代码托管平台成立时间够早用户量也够大。它的定位不是“GitLab 替代品”而是一个独立的“中国版代码托管服务”所以不能说它只是 GitLab 的换皮。Gitee 的核心优势是“省心”打开网页注册就能用中文界面国内访问速度快自带 Issue、Pull Request、Wiki、Pages、企业版等功能。生态上Gitee 和国内常用的团队协作工具集成得不错很多开源项目在 Gitee 上也有官方镜像仓库拉代码的速度确实比从海外站点拉快很多。对于个人开发者、高校教学、国内中小团队Gitee 的学习成本和部署成本几乎可以忽略。Gitee 也有企业版和私有化部署方案只不过产品逻辑和 GitLab 那种“组-子组-项目”的严格层级模型不完全一样需要重新适应。1.4 自建 GitLab CE能折腾的人的另一个答案最后还有一个绕不开的选项——自己搞一台服务器用 Docker 或者 Omnibus 方式部署一套 GitLab Community Edition。这个方案不是“国产”但它经常出现在“GitLab 替代”的搜索结果里原因也很简单很多团队既不想用国外 SaaS又不想被平台绑定他们需要的只是一套私有部署的代码托管系统至于底座是谁都行。自建 GitLab CE 的优点是自主性最强数据和权限完全在自己手里而且只要内存给够功能对大多数团队来说完全够用。但代价是运维成本系统升级、备份恢复、安全补丁、存储扩容、CI Runner 维护这些都是实打实的工作量。所以我的建议是如果团队没有专职运维谨慎选择这条路。2. 核心功能逐项对比Gitee、极狐 GitLab 与自建 GitLab 差在哪2.1 功能矩阵一图看懂为了直观我整理了一张对比表覆盖大多数团队选型时最关心的维度。这里的“自建 GitLab CE”指的是你自己搭的社区版极狐 GitLab 以企业版的私有化部署为例。对比维度GiteeSaaS极狐 GitLab私有化/SaaS自建 GitLab CE国内访问速度很快很快国内节点/本地部署取决于服务器带宽中文支持原生中文原生中文社区版基本无原生中文化需自行搞定私有仓库免费版有数量和人数限制按版型收费无仓库数量限制无限制权限模型企业/团队/仓库Group/Subgroup/ProjectGroup/Subgroup/ProjectCode ReviewPull RequestMerge RequestMerge RequestCI/CDGitee Go需开通GitLab CI/CD原生GitLab CI/CD原生Pages 静态站点Gitee Pages需实名审核GitLab PagesGitLab PagesAPI 生态有 OpenAPIREST API GraphQLREST API GraphQL私有化部署企业版支持支持可适配国产化环境支持运维成本零平台托管低到中取决于部署方式高从这个表能看出一个趋势如果你要的是“开箱即用的代码托管”Gitee 最合适如果你要的是“和 GitLab 一样的完整 DevOps 平台”极狐 GitLab 或者自建 GitLab 才是真正匹配的。2.2 权限与协作模型差异GitLab 之所以受大团队欢迎一个核心原因是它把权限体系设计得非常细从顶级 Group 到 Subgroup再到 Project成员权限可以一级一级继承也可以单独覆盖。这种“组-子组-项目”的结构天然适合有多条产品线、多个团队、多个仓库的企业。你在 GitLab 里可以很自然地建一个 Parent Group 叫 company下面按业务线拆 frontend、backend、data然后每个 Subgroup 里再放具体项目。Gitee 的权限模型更贴近国内用户习惯企业下有团队团队下有仓库权限粒度也有管理员、开发者、观察者等角色日常够用。但如果你要跨多个项目做统一的成员管理和权限审计Gitee 的企业版会比个人版好用而免费的个人版在多人协作上会有明显限制。所以团队一旦超过 5 人或者项目超过一定数量还是要认真考虑企业版或者直接上类似 GitLab 的模型。这里尤其要提醒如果你们团队是刚从 GitLab 切过来成员角色和审批流的设置思路要提前对齐要不然老员工按 GitLab 的习惯去 Gitee 上建 Group会发现概念对不上容易绕弯路。2.3 CI/CD 能力对比几行配置和托管的距离GitLab CI/CD 为什么被人津津乐道因为你只需在仓库根目录放一个 .gitlab-ci.ymlGitLab Runner 就会按文件里的 stages 和 job 定义去跑构建、测试、部署。这种“配置即流水线”的思路让 CI/CD 和代码仓库天然绑定一套机制搞定所有项目。Gitee 也有自己的 CI/CD 能力叫 Gitee Go提供构建、测试、部署等流水线能力而且支持公共构建机和私有构建机。一般需要在仓库里手动开通流水线功能再选择模板或者编写 YAML 配置。和中大型团队的深度 CI/CD 需求比起来Gitee Go 的插件生态和社区资料相对少一些部分高级能力在免费版里也有限制。换句话说如果团队已经有成熟的 GitLab CI 配置迁移到 Gitee 后大概率要把流水线重写一遍如果团队本来就没有固定的 CI/CD 方案从零开始在 Gitee Go 上搭建也不算难。2.4 页面托管与开源生态Pages 功能是两个平台差异比较明显的地方。Gitee Pages 需要先实名认证部署静态站点时需要选择分支、目录和构建命令支持 Jekyll、Hugo、Hexo 等常见静态站生成器发布后默认是 gitee.io 子域名。如果绑定自定义域名就需要按照国内要求完成 ICP 备案。Gitee Pages 还有一个“内容审核”环节发布后不会立刻生效需要等审核通过。GitLab Pages 走的是另一条路你用 CI 配置一个 pages job把构建产物放到 public 目录Runner 跑完自动发布。整个过程不需要人工审核权限和 TLS 证书的管理也更灵活。极狐 GitLab 在国内运营时Pages 的域名和合规策略也遵循国内规则但在使用体验上更接近原生 GitLab。开源生态方面Gitee 的优势是“镜像多、拉得快”很多热门的开源项目在 Gitee 上有官方镜像比如 ERPNext 这类大型项目国内开发者直接 clone 镜像仓库速度比从海外拉快得多。极狐 GitLab 的生态更多是面向企业的GitLab 自带的模板库、安全扫描、依赖审计这些能力Gitee 目前还没有完全对标。3. 部署实践Docker 自建与私有化部署怎么落地3.1 用 Docker 快速拉起一套 GitLab如果你想先体验自建 GitLab最推荐的方式就是用 Docker。以 Ubuntu 服务器为例先确保有 Docker 和 docker-compose然后创建挂载目录再启动容器。mkdir -p /srv/gitlab/config /srv/gitlab/logs /srv/gitlab/data docker run -d \ --name gitlab \ --hostname gitlab.example.com \ -p 8443:443 -p 8080:80 -p 2222:22 \ -v /srv/gitlab/config:/etc/gitlab \ -v /srv/gitlab/logs:/var/log/gitlab \ -v /srv/gitlab/data:/var/opt/gitlab \ --restart always \ gitlab/gitlab-ce:latest这里有几个细节值得说明。第一hostname 不要随便填 localhost后面 SSH clone 地址会用到它填一个你打算长期使用的域名或者服务器 IP 更省事。第二端口映射中的 22 映射到宿主机的 2222是因为很多服务器上 22 已经被 SSH 占用了。第三首次启动后 GitLab 会有一个初始化过程可以用docker logs -f gitlab观察进度看到 “gitlab Reconfigured!” 之类的日志后再访问页面。注意GitLab 首次启动时会在/etc/gitlab/initial_root_password里生成 root 的临时密码用docker exec gitlab cat /etc/gitlab/initial_root_password查看。这个文件只在 24 小时内存在登录后要立刻改密码。3.2 资源评估内存别只给 1G自建 GitLab 最容易翻车的就是内存不够。官方推荐的最低配置是 4GB 内存实测下来 4GB 只是“能跑”开几个项目、跑一次流水线内存就吃紧了。如果机器只有 2GB我会非常不建议硬装因为 GitLab 是 Rails 应用本身有 Puma、Sidekiq、PostgreSQL、Redis 等一堆进程常驻内存内存不足时系统会疯狂 swap页面打开要等几十秒。我自己的经验是小型团队5 人以内用 4GB 内存的服务器能做基础托管稳妥起见给 8GB如果还要跑 GitLab Runner 和 Pages16GB 更踏实。另外硬盘要留足余量Git 仓库的 .git 目录增长速度比你想象得快。3.3 内存占用过高怎么调优热词里有人搜“docker gitlab 占用内存过多”这确实是自建党最常遇到的问题。我遇到过一台 8GB 的服务器装完 GitLab 后 free -h 一看可用内存只剩 1GB 多。排查后发现主要是两个原因默认的 Puma worker 数量太多以及 Prometheus 全家桶全开。优化方法很直接改/etc/gitlab/gitlab.rb# 根据 CPU 核数调整一般 2-4 个 worker 就够 puma[worker_processes] 2 puma[min_threads] 4 puma[max_threads] 8 # 关闭不用的监控组件 prometheus_monitoring[enable] false alertmanager[enable] false node_exporter[enable] false # 限制 Sidekiq 并发 sidekiq[max_concurrency] 5改完执行gitlab-ctl reconfigure和gitlab-ctl restart内存能降下来不少。如果你用的是 Docker 部署这个文件就是挂载目录里的/srv/gitlab/config/gitlab.rb改完后再重启容器。其次是注意 Gitaly 产生的临时文件尤其是大仓库频繁 GC 时磁盘占用也会飙升。3.4 Gitee 与极狐 GitLab 的私有化部署形态Gitee 的私有化部署主要通过 Gitee Enterprise 提供客户可以基于自己的服务器或者云主机部署具体能力包括企业内网访问、LDAP 登录对接、权限管控等。这类方案适合对数据隔离要求高、但又不想自己搭一套 GitLab 的团队。极狐 GitLab 私有化部署则以 GitLab 原生的 Omnibus 包或者 Helm Charts 为主支持离线安装和升级。相对自建 GitLab CE极狐 GitLab 在合规层面多做了很多工作也支持 x86 和 ARM 等不同架构对国产化环境和信创要求的适配是它的核心卖点之一。如果你所在的企业在招标时有明确的国产化诉求极狐 GitLab 的资质和案例会比 Gitee 更“对味”。顺便提一句极狐 GitLab 也提供 SaaS 版本不想管服务器的话可以先从 SaaS 体验。4. 实操环节从 SSH 配置到仓库迁移跑通全流程4.1 多平台 SSH 密钥管理一个账号都不能乱很多人同时用 Gitee 和 GitLab一开始最懵的就是 SSH 密钥。你们搜到的“本地全局设置了 gitee 和 github 两个库冲突”就是典型问题如果你只生成了一把默认的 id_rsa把公钥同时加到 Gitee 和 GitLab第一次clone可能没问题但一旦涉及多账号同时使用Git 会傻掉。解决方案是给每个平台生成独立密钥然后通过~/.ssh/config做路由区分。ssh-keygen -t ed25519 -C your_emailexample.com -f ~/.ssh/id_ed25519_gitee ssh-keygen -t ed25519 -C your_emailexample.com -f ~/.ssh/id_ed25519_gitlab然后编辑~/.ssh/configHost gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_ed25519_gitee IdentitiesOnly yes Host gitlab.example.com HostName gitlab.example.com User git IdentityFile ~/.ssh/id_ed25519_gitlab IdentitiesOnly yes这样 clone Gitee 仓库时Git 自动用 Gitee 密钥clone 你自己的 GitLab 服务器时则用另一把密钥。再用ssh -T gitgitee.com测试能返回欢迎信息就说明配置成功。还有一个小细节如果你从 GitLab 切到 Gitee容易在本地仓库里残留旧的 user.name 和 user.email。可以用下面的命令在项目目录单独覆盖git config user.name your_gitee_username git config user.email your_emailexample.com这样可以避免提交记录里挂错身份。4.2 仓库迁移从 GitLab 搬家到 Gitee 的两种方式仓库迁移分两种情况只迁代码或者连 Issue、MR、Wiki 一起迁。只迁代码的最快方式是 mirror 模式git clone --mirror gitgitlab.example.com:group/project.git cd project.git git remote set-url origin gitgitee.com:username/project.git git push --mirror origin这个方式会把所有分支、标签都带去适合代码仓库搬迁。但它不会带 GitLab 里的 Merge Request 和 Issue因为这些不是 Git 数据而是平台数据。想保留 Issue 和 MR就得用平台自带的导入工具。Gitee 提供“从 Git/GitLab 导入”的入口在新建仓库或仓库管理后台里可以找到。GitLab 侧需要先生成 Personal Access Token然后在 Gitee 导入向导里填 GitLab 地址、用户名和 Token。极狐 GitLab 同理它是 GitLab 产品导出和导入机制与 GitLab 一致。整体体验下来平台的导入功能已经足够成熟几万个 Issue 的项目也能搬到七七八八只是要注意 URL 映射和用户映射有些历史提交关联的可能不准这个只能接受。4.3 CI/CD 最小配置让流水线跑起来在 GitLab 侧跑通 CI/CD 需要两步配置 Runner 和编写 .gitlab-ci.yml。如果只想在本地体验可以安装一个 GitLab Runner 并注册为 shell executor如果是企业环境更推荐使用 Docker executor。一个最小可用的 Node.js 项目配置大概是这样的stages: - build - test build-job: stage: build script: - echo Starting build... - npm install artifacts: paths: - dist/ test-job: stage: test script: - echo Running tests... - npm test only: - main提交这个文件后GitLab 会自动识别并触发流水线。这里面的核心逻辑是每个 job 必须声明属于哪个 stage同一个 stage 的 job 可以并行stage 之间按顺序执行。artifacts可以把构建产物传给后续 job比如再部署到测试服务器。Gitee 侧则是在仓库里开通 Gitee Go然后配置流水线。我个人的感受是如果你已经熟悉 GitLab CI 的 YAML 语法到 Gitee Go 会有一段适应期因为两者的配置方式和触发机制不完全一样。但如果团队本来没有固定 CI 方案直接学 Gitee Go 也没问题。4.4 Gitee Pages 与 GitLab Pages静态站点部署差异静态托管这一块两者最容易搞混我单独拿出来说。Gitee Pages 的开启条件是实名认证然后在仓库的“服务”菜单里找到 Pages选择部署分支、目录填写访问子域名提交后进入审核。审核通过后站点才能访问。这个流程对普通个人博客用户足够用缺点是发布不是实时的想要更新得快就得接受审核等待。GitLab Pages 则是通过 CI 自动发布的你需要在仓库里加一个 pages jobpages: stage: deploy script: - mkdir -p public - echo Hello Pages public/index.html artifacts: paths: - public only: - mainRunner 跑完后GitLab 会自动把 public 目录发布为 Pages 站点。整个过程无人工审核适合团队内部文档站、组件库预览站这类频繁更新的场景。极狐 GitLab 的 Pages 在域名和合规上遵循国内规则如果你部署的是内网环境完全可以用内部域名做 Pages非常方便。5. 常见问题与排查心得这几类坑我基本都踩过5.1 IDE 连接提示 login failedtoken 和版本都要查热词里有一条很典型“login failed. check api token or gitlab version.” 这个报错在 VS Code 的 GitLab 插件、以及各种 Git 客户端里经常出现它有两层含义一是 API Token 不对二是 GitLab 版本太老或太新和插件调用的 API 版本不匹配。我碰到过最多次的是 Token 权限不足。解决问题分三步先在 GitLab 里生成一个 Personal Access Token勾选api和read_repository权限然后检查填的 GitLab 地址是https://gitlab.example.com而不是https://gitlab.example.com/这种带斜杠的地址最后确认 GitLab 版本不要太离谱。老版本 GitLab 的 API 兼容性差很多新插件默认按新版 API 调用如果公司还在用 13.x 之类的老版本建议让管理员考虑升级否则只能换旧版插件。5.2 pack 文件几十 G仓库膨胀的清理思路“gitlab pack 文件很大”也是高频问题。GitLab 仓库跑久了.git/objects/pack里的 pack 文件会越来越大最典型的原因是有人误提交了大文件比如几百 MB 的安装包、编译产物、视频素材然后即使后面删掉了提交历史里还留着导致每次 clone 都要下载几十 GB。排查大文件可以用这条命令git rev-list --objects --all \ | git cat-file --batch-check%(objecttype) %(objectname) %(objectsize) %(rest) \ | awk $1blob {print $3, $4} \ | sort -rn | head -20找出大文件后用git filter-repo或者 BFG Repo-Cleaner 清理历史再强推所有分支最后在 GitLab 里触发一次仓库 GC。这个过程会重写提交历史必须通知所有协作者重新 clone否则会乱套。清理之后git count-objects -vH能看到 pack 文件明显变小。5.3 账号 pending approval不是等一等就行如果你的 GitLab 账号登录后提示 “your account is pending approval from your gitlab administrator and hence blocked”说明账号没有被管理员批准。这个情况常见于企业版开启了用户审批或者通过 LDAP/SSO 同步的新用户还没来得及审核。解决办法不是等而是找管理员在 Admin Area - Users 里找到对应用户点击 Approve。如果是极狐 GitLab 的 SaaS 版需要联系客服或超管处理。这里有个小技巧公司里经常有人注册后没被注意到顺手在审批列表里批量通过一批即可别让流程卡在审批环节。5.4 Gitee 创建 issue 验证码老错先别急着怪验证码Gitee 上创建 Issue 时偶尔会遇到验证码明明输对了却提示错误的情况。我自己的经验是先刷新页面重试一次大概率能通过如果还不通过清理浏览器缓存或者换无痕窗口再不行检查一下是不是浏览器插件拦截了验证码请求特别是广告拦截类插件。另外一个比较隐蔽的原因是账号触发了风控比如短时间内创建 Issue 太频繁或者 IP 频繁变化。这种情况下换一个网络环境再登录一般就能恢复正常。如果是在公司内网统一出口经常被验证码折磨是正常现象找运维同事要个固定出口 IP 反而更省心。5.5 双平台仓库目录配置冲突的细节回到“本地全局设置了 Gitee 和 GitHub 两个库冲突”的问题除了用~/.ssh/config区分密钥外还有一种情况是 Git 的用户名和邮箱被全局配置覆盖了。因为很多人装完 Git 会执行git config --global user.name xxx后面克隆 Gitee 仓库时也沿用这个身份提交记录里就会挂错人。解决办法要么在项目目录覆盖 user.name 和 user.email要么用 Git 2.19 支持的includeIf按目录自动切换配置。比如在~/.gitconfig里写[includeIf gitdir:~/work/gitee/] path ~/.gitconfig-gitee [includeIf gitdir:~/work/gitlab/] path ~/.gitconfig-gitlab然后把对应的用户名邮箱分别写进~/.gitconfig-gitee和~/.gitconfig-gitlab。这样只要仓库目录放对了身份自动切换不会再混。最后说点个人体会我在实际选型中有一个很深的感受别被“国产替代”四个字绑架。如果你的团队已经在用 GitLab而且依赖它的 CI/CD 和权限体系那么容易迁移的路径是先上极狐 GitLab因为操作习惯、API、CI 配置都能沿用迁移成本最低。如果你们是刚起步、没有历史包袱的个人或小团队Gitee 的开箱即用体验非常好注册之后十分钟就能把仓库建起来Pages 也能解决官网展示问题没必要一上来就自建 GitLab。至于自建 GitLab CE我坚决建议的前提是团队里有人愿意持续维护它否则出了故障没人处理比用 SaaS 更耽误事。最后给大家一个小技巧不管最后选哪个平台先把 SSH 密钥、user.name、user.email 这套账号体系理清楚再把仓库的备份和恢复方案定下来比研究功能列表有意义得多。代码托管平台可以换数据丢了真的是谁都救不了。