企业官网建设流程全解析

先说个我自己的经历。前两年在一家做企业服务的公司带研发团队，代码从 SVN 迁到 GitLab，原以为万事大吉，结果隔三差五就有人来找我：拉取代码超时、CI 跑着跑着连接断掉、升级版本还要在公司群里求爷爷告奶奶找人搞代理。那会儿团队里就有人问过一句："有没有国产 GitLab？"当时我没当回事，直到后来深入研究 Gitee 和极狐 GitLab，才发现这个问题背后藏着一整条选型路线。这篇文章就把我对这两类主流替代方案的对比、实测经验、迁移过程和踩坑记录完整梳理一遍，给正在纠结"要不要换、换哪个"的朋友一个实在的参考。

1. 先搞清楚：GitLab 在国内的"水土不服"到底卡在哪

1.1 不是功能不够，而是这几个现实问题

先别急着骂 GitLab 不行。单论功能，GitLab 依然是目前市面上最完整的 DevOps 平台之一，从代码托管、MR 审查、CI/CD、安全扫描到运维观测，一套全给你包圆了。但"功能强大"和"用着顺心"是两码事，尤其在国内的生产环境里，原版 GitLab 会碰到几个绕不开的现实问题。

• 官方镜像和软件源的访问门槛：安装 GitLab 时，如果用官方源或者 Docker Hub 官方镜像，速度不稳定是家常便饭。很多团队的服务器还是内网环境，连外网都得过一层跳板，装一次 GitLab 能折腾一下午。我见过有人干脆用离线包装，可离线包版本更新又成了新的麻烦。
• 中文本地化不彻底：GitLab 官方其实有中文界面，但翻译覆盖率不是 100%，一些二级页面和错误提示还是英文。对纯国内研发团队来说，知道怎么点"New project"的人不少，但能看懂"Pipeline failed"底层日志的人真不多。
• 技术支持基本靠社区：社区版没有官方技术支持，出了问题只能自己翻 Issue、搜 Stack Overflow。真遇到生产环境数据损坏或者升级失败，那种孤立无援的感受，经历过的人都懂。
• 合规与数据驻留要求：一些政企、金融、医疗类项目，明确要求代码数据必须存放在境内、由境内主体运营。原版 GitLab 的 SaaS 服务在数据主权这块根本没法满足要求，这也是很多人找"国产 GitLab"最直接的动因。

1.2 从热搜词里看到的真实痛点

我在整理这篇文章之前，特意去看了一圈 GitLab 和 Gitee 相关的热搜词，基本能拼出大家日常使用的真实场景：

• "gitlab login failed. check api token or gitlab version"：登录报错，大概率是 API Token 失效或者版本兼容问题。
• "your account is pending approval from your gitlab administrator"：账号注册后需要管理员审批，这在企业自建环境里很常见。
• "docker gitlab 占用内存过多"：GitLab 出了名的吃内存，Docker 部署时不做限制能把宿主机拖垮。
• "gitlab pack 文件很大"：仓库打包文件膨胀，克隆和拉取越来越慢。
• "gitlab高危漏洞修复方案"：安全团队隔三差五扫出漏洞，修复要动配置、要重启服务，极其痛苦。
• "gitee pages"、"gitee 使用教程"、"gitee 拉取和上传项目"：大量用户在转向 Gitee 的过程中需要基础操作指导。
• "gitlab仓库代码量和注释率统计"：管理层要数据，但 GitLab 原生统计功能偏弱，得自己写脚本或者接第三方工具。

这些问题组合在一起，就是一幅很完整的用户画像：国内中小型研发团队，受够了原版 GitLab 的速度和运维成本，想找一个更接地气的替代品，但又怕功能缩水、迁移过程太疼。

2. Gitee（码云）：最像"国产 GitHub"，但离 GitLab 还有多远

2.1 Gitee 的核心能力盘点

Gitee（码云）是国内用户接触最多的代码托管平台，背靠开源中国，成立时间早，用户基数大。很多人把它类比成"国产 GitHub"，这个定位本身没什么问题，因为它的核心场景确实是公有云托管。

Gitee 提供的能力包括：

• 无限私有仓库（有一定成员数限制）和公开仓库托管；
• Pull Request 工作流，支持代码审查、评论、冲突检测；
• Gitee Pages：静态站点托管，很多个人博客、前端 Demo 都在用它；
• Gitee Go：CI/CD 流水线服务，类似 GitHub Actions；
• Issue 管理、里程碑、看板：基础项目管理能力都有；
• 企业版：支持私有化部署，提供 LDAP/钉钉/企业微信集成、权限管理、审计日志等企业级功能。

对于个人开发者、开源项目和三五人的小团队来说，Gitee 的免费额度基本够用，上手成本极低，注册个账号就能用，不用管服务器、不用处理 SSL 证书、不用半夜爬起来修备份。

2.2 Gitee 在企业自建场景的硬伤

但如果你拿 Gitee 当"GitLab 替代品"，而且是打算在企业内部长期用，你会发现几个很现实的问题：

第一，Gitee 的私有化部署版本门槛较高。官方主推的是 SaaS 服务，企业版私有化部署需要联系销售谈合同，价格不透明，很多中小团队根本够不着。搜索结果里大量出现"gitee 私有化部署"相关的求助帖，说明需求很大，但官方能自助搞定的人不多。

第二，CI/CD 能力与 GitLab CI 不在一个量级。GitLab CI 的杀手锏是.gitlab-ci.yml一套文件走天下，运行器可以自己搭、随便扩容，日志和流水线视图深度集成在代码仓库里。Gitee Go 也能做，但流水线能力、缓存机制、构建时长配额、可定制性都相对弱。真到了复杂构建场景，会觉得束手束脚。

第三，代码托管之外的生态偏单薄。GitLab 的 Container Registry、依赖代理、安全扫描、合规策略这些都是平台内生的，Gitee 更偏向"代码仓库 + 基础协作"。虽然可以通过 Webhook 接第三方工具，但整体协同体验不像 GitLab 那么"全家桶"。

第四，平台属性带来的不确定感。公有云托管意味着你的代码在别人服务器上，虽然 Gitee 安全记录整体还行，但政企项目和重视知识产权的公司对此会有顾虑。另外，公有云平台的风控策略、功能调整、收费模式都可能随时变化，这不是某家公司特有的问题，而是所有 SaaS 平台共有的"租户感"。

2.3 从 Gitee 使用中的几个细节问题说起

我在给一些朋友做技术咨询时，被问到过不少 Gitee 的具体问题，印象比较深的有这几个：

• SSH Key 配置：Gitee 的 SSH Key 添加入口藏得有点深，很多新手用户第一次配置时找不到地方。其实路径是：头像 → 设置 → 安全设置 → SSH 公钥，然后把本地生成的公钥贴进去就行。
• 拉取上传权限问题：用 TortoiseGit 拉取 Gitee 仓库失败，大半原因是分支权限、仓库可见性或者 SSH Key 没配对。遇到这种问题先检查仓库地址里用的是 HTTPS 还是 SSH，再确认当前账号有没有该仓库的访问权限。
• 验证码错误：创建 Issue 时验证码明明输对了却提示错误，一般是浏览器缓存或插件拦截导致的，清理缓存换无痕模式基本能解决。
• 多账号冲突：本地同时配了 GitHub 和 Gitee 的 SSH Key，会出现"两个库冲突"的情况。解决办法是给不同 Host 配置不同的 HostName，而不是强行覆盖同一个公钥。

这些细节并不代表 Gitee 不好，而是在提醒我们：Gitee 的目标用户和使用场景，和 GitLab 其实不太一样。

3. 极狐GitLab（JiHu GitLab）：官方中文本土化的正确姿势

3.1 极狐到底是什么来头

很多人第一次听到"极狐GitLab"会有点懵，这名字和 GitLab 有什么关系？是山寨吗？还真不是。极狐信息技术（湖北）有限公司是 GitLab 与中国合作伙伴成立的合资公司，简单说就是GitLab 官方在中国的运营主体，推出的极狐GitLab 是 GitLab 的"中国定制版"。

这个身份意味着几件事：

• 代码和内核跟 GitLab 官方保持同步，不会出现"换了皮但功能落后"的情况；
• 服务器和数据可以部署在国内，解决数据驻留和访问速度问题；
• 有本地化技术支持团队，出了事能找到说中文、懂业务的人；
• 界面做了深度汉化，而且会根据国内用户的使用习惯调整交互细节。

所以如果你说"有没有国产 GitLab"，极狐GitLab 其实是最适合回答这个问题的一个选项——它既保留了 GitLab 的完整能力，又在合规、速度、支持上针对国内市场做了重新适配。

3.2 版本与功能对比：到底要不要花钱

极狐GitLab 的版本体系跟 GitLab 官方基本对齐，主要分三个层级：

我的建议是：如果团队规模在 10 人左右，先从 Free 版用起，完全够用。等涉及到多环境部署、需要让安全团队介入代码审计、要做精细化权限控制的时候，再考虑升 Premium 或 Ultimate。

有一点要特别提醒：极狐GitLab 的 Free 版和社区版功能几乎一致，但极狐的 SCM 服务在私有化部署时是商业授权模式，不能理解为"社区版换个名"。预算特别紧张、又必须走纯开源路线的团队，可以考虑 GitLab CE + 国内镜像源自己部署，但运维成本和技术支持问题就需要自己扛了。

3.3 部署方式：Omnibus、Docker、K8s 实测经验

极狐GitLab 支持多种部署方式，我实际用过的有三种，分别说下体验：

Omnibus 包安装（推荐小规模）

极狐官网提供了 RPM/DEB 包，直接安装在 Ubuntu/CentOS 上，一条命令初始化配置，最适合单机环境。

# 以 CentOS 7 为例（极狐提供的是国内 yum 源，速度很稳） sudo yum install -y gitlab-jh sudo gitlab-ctl reconfigure

装完以后浏览器访问服务器 IP 就能看到界面，首次登录会要求设置 root 密码。这种方式的优点是省心，备份、升级、日志都有现成命令；缺点是亲和单机，高可用要自己折腾。

Docker 部署（推荐快速验证）

用 Docker 跑极狐GitLab 是很多人的首选，因为隔离性好、不污染宿主机环境。

# docker-compose.yml 示例 version: '3' services: gitlab: image: registry.gitlab.cn/omnibus/gitlab-jh:latest container_name: gitlab-jh restart: always hostname: gitlab.example.com ports: - "80:80" - "443:443" - "22:22" volumes: - /srv/gitlab/config:/etc/gitlab - /srv/gitlab/logs:/var/log/gitlab - /srv/gitlab/data:/var/opt/gitlab shm_size: '256m'

这里面有个非常关键的参数：shm_size。GitLab 依赖 PostgreSQL，如果共享内存设置太小，数据库会出各种奇怪问题。我见过有人没配这个参数，跑一段时间后 GitLab 频繁 500，日志里全是 PostgreSQL 的报错，加了这个参数后世界就清净了。

K8s 部署（推荐规模化运维）

极狐GitLab 的 Helm Chart 很成熟，支持在 Kubernetes 集群里一键部署，适合已经有容器化运维能力的团队。不过要提醒一句：GitLab 全家桶上 K8s 的资源消耗比单机部署大得多，而且排障难度也上一个台阶。如果你不是 DevOps 能力特别强的团队，建议谨慎选择这条路。

4. 功能逐项硬碰硬：自建 vs 托管，这几项最见真章

4.1 CI/CD 能力对比：.gitlab-ci.yml仍然是核心武器

我团队里最离不开 GitLab 的功能就是 CI/CD。用.gitlab-ci.yml定义构建、测试、部署流水线，代码一推自动跑，不想让成员直接改生产环境就靠这个控制。极狐GitLab 继承了这套完整能力，还内置了 Container Registry，镜像构建完直接推上去，后续部署从 Registry 拉，流程一气呵成。

Gitee 的 Gitee Go 也可以定义流水线，但有几个限制让我不太舒服：

• 构建时长配额有限，免费额度跑复杂项目容易不够；
• Runner 必须用官方托管的，不能像 GitLab 那样自建 Runner，灵活性和隔离性都有差距；
• 流水线模板库的丰富程度不如 GitLab 社区生态。

如果你的团队依赖 CI/CD 做自动化交付，那么极狐GitLab 在架构上更接近"正主"，Gitee 更适合轻量自动化。

4.2 代码审查与合并请求体验：MR 流程的细节差异

代码审查是研发质量的生命线，这块我特别看重。

极狐GitLab 的 Merge Request 支持：代码所有者强制审批、多级审批规则、MR 内讨论、机器人提醒、冲突在线解决、一键合并。管理员还可以在项目设置里规定"必须通过流水线才能合并"，从制度上杜绝"测试没过就上线"。

Gitee 的 Pull Request 流程也能用，基础功能都有——创建、评论、审查、合并。但细节上不够细腻，比如 MR 的审批规则配置、分层权限、与 CI 状态的深度联动都不如 GitLab 成熟。

4.3 权限模型、合规与审计：企业级分水岭

这里想单独拿出来说，因为很多团队一开始不重视权限，等出事才后悔。

GitLab 的权限模型是"组织（Group）→ 子组（Subgroup）→ 项目（Project）"三层结构，配合成员角色（Guest/Reporter/Developer/Maintainer/Owner）可以做到非常细粒度的控制。比如"外包人员只能看自己负责的项目，不能看其他组的代码，更不能动生产分支"这种需求，在 GitLab 里配置起来是顺手的事。

Gitee 的权限模型相对扁平，更偏向"仓库所有人/成员/协作者"这样的平级关系。对一个大型组织做分级管理会比较吃力，尤其是子分组、继承权限这些高级需求，Gitee 的表现不够好。

在合规审计上，极狐GitLab 提供了审计事件日志，谁在什么时间做了什么操作都能查到；Gitee 企业版也有基础审计日志，但粒度不够深。

4.4 迁移过程中的账号与权限连贯性

这里插入一个实操中容易忽略的点。从 GitLab 迁移到 Gitee 或者极狐GitLab 时，账号体系和权限映射是最容易出问题的环节。

GitLab 的权限主要靠 Group 结构实现，而 Gitee 的权限更多是仓库级别的。如果你原来在 GitLab 里建了一堆 Group 和子 Group，迁移到 Gitee 后很可能发现"Group 结构没了，权限全乱了"。极狐GitLab 因为是同源系统，Group、权限、成员角色都是原生支持的，迁移几乎是"平移"。

我们当时迁移时踩过一次坑：某外包组在旧 GitLab 里只能访问特定子项目，迁到新平台后因为权限映射没同步，导致他们能看见公司全部仓库。好在发现及时，没造成实际泄漏。这个教训让我养成了一个习惯：任何代码平台迁移，第一步永远是把权限模型画清楚，再动代码。

5. 迁移实操：从 GitLab 迁到国产替代方案的关键动作

5.1 迁移前的盘点清单

代码迁移这事，最怕"上来就 git push"。我建议你先花半天时间做一次盘点，列一个清单：

• 仓库数量和代码量：确认哪些仓库要迁、哪些可以归档；
• 分支和标签策略：保留哪些长期分支，历史标签是否都要保留；
• MR/Issue 历史：这些要不要一并迁移，还是只迁移代码不要历史；
• CI/CD 流水线：.gitlab-ci.yml里的 runner、变量、缓存策略都需要在目标平台重建；
• Webhook 和外部集成：钉钉/企业微信通知、Jira/禅道关联、自动部署钩子等；
• 账号和权限：如上文所说，先把 Group/成员/角色对应关系梳理清楚。

5.2 Gitee 导入和极狐迁移的实测对比

Gitee 迁移实测

Gitee 支持直接从 GitHub 和 GitLab 导入仓库，路径是："新建仓库 → 选择导入仓库 → 填目标地址"。如果是公开仓库和私有仓库，分别用 HTTPS 和 SSH 地址导入。

但实测下来，Gitee 导入工具对大型仓库支持一般，几百 MB 以上的仓库容易出现超时、导入失败。我的建议是：先试小仓库，摸清规律，再迁移大仓库。

极狐GitLab 迁移实测

极狐GitLab 和 GitLab 同源，迁移工具也保留了 GitLab 的强力功能：

• 仓库迁移：用git push --mirror把整个仓库（包括所有分支和标签）镜像推送过去；
• Group 迁移：通过 GitLab API 批量创建 Group 和 Project，再写脚本迁移权限；
• MR/Issue 历史：官方支持从 GitLab 导入整个项目（包含 Issue 和 MR），不过要注意版本差异，老版本迁移到新版本时可能会丢一些自定义字段。

一个简单可用的仓库镜像迁移命令：

# 在本地创建裸仓库，然后镜像推送到新平台 git clone --bare http://old-gitlab.example.com/your-group/your-project.git cd your-project.git git push --mirror http://new-gitlab.example.com/your-group/your-project.git

5.3 团队过渡期的几个建议

迁移不是技术活，更是管理活。这里有几个过来人的建议：

• 新旧并行跑两周：别一刀切切换，给团队适应和反馈的时间；
• 统一文档和操作规范：团队里总有几个人不熟悉新平台，写一个简明手册比一次次答疑省力；
• 找一个"新平台内部顾问"：让一个学习能力强、愿意接受新工具的工程师先深度试用，然后由他给其他人培训，比外聘讲师效果好太多。

6. 部署与运维避坑：几个真实踩坑记录

6.1 关于"docker gitlab 占用内存过多"

GitLab 出名地吃资源，最基础的部署内存建议 4GB 起步，实际跑起来 Puma、Sidekiq、PostgreSQL、Redis 好几个进程常驻。Docker 部署如果不做资源限制，宿主机的内存会被 GitLab 慢慢吃光。

我踩过一次比较深的坑：在一台 8GB 内存的开发机上用 Docker 跑了一个 GitLab，没设内存限制，结果 GitLab 自己占到了 5GB，宿主机越来越卡，最后 SSH 都连不上。

现在的做法是启动容器时显式加资源限制：

docker run --detach \ --publish 8443:443 --publish 8080:80 --publish 8022:22 \ --name gitlab \ --restart always \ --memory 4g \ --memory-swap 4g \ --shm-size 256m \ registry.gitlab.cn/omnibus/gitlab-jh:latest

另外有几个优化 GitLab 内存的小技巧：

• 减少puma工作进程数，单机环境配 2~4 个足够；
• 关闭不需要的模块（如不需要的监控、Prometheus 自带导出器等）；
• 定期清理旧 CI 构建产物，避免数据目录无限膨胀。

6.2 关于"gitlab pack 文件很大"

仓库越用越大，克隆越来越慢，一查发现.git/objects/pack下的文件撑到几个 GB——这是很多团队的共同痛点。

常见原因和处理方式：

• 历史大文件：有几次有人提交了几百 MB 的资源包、模型文件或日志，后来删掉了，但记录还在仓库历史里。解决办法是用git filter-repo重写历史，或者用 Git LFS 管理大文件。
• CI 缓存误提交：有些人把构建产物、依赖目录dist/、node_modules/顺手提交上去，这在.gitignore没配好时特别容易发生。
• 频繁变动的二进制文件：设计稿、PDF、固件包等，每次都完整生成一个新版本提交到仓库。

处理方式第一步永远是清理：git filter-repo --path-glob '*.zip' --invert-paths这种命令把历史中的大文件摘掉，然后让所有成员重新克隆。注意，重写历史会影响所有基于该仓库的分支，操作前一定要确认大家都把自己的本地分支推送并备份了。

6.3 关于"gitlab高危漏洞修复方案"

安全扫描是很多公司必须过的关口，GitLab 隔一段时间就会被曝出高危漏洞。修复方案多数时候就是升级到修复版本，但真正麻烦的是升级过程。

我的做法是：

1. 先看极狐官网和 GitLab 官方 Release 的安全公告，确认影响版本和修复版本；
2. 找一台测试机，同样的部署方式先升级验证，跑一遍冒烟测试；
3. 选择业务低峰期，备份后升级生产环境；
4. 升级完检查 GitLab 状态、登录、仓库、CI 是否正常。

这里特别建议：如果用了极狐GitLab，优先关注它的安全公告，国内团队获取这些信息会比直接看英文站快很多。另外有条件的话给 GitLab 服务套一层 WAF，即使有未公开漏洞，也能降低外部扫描直接打进来的概率。

6.4 备份与容灾：没人提醒你就要自己注意的事

GitLab 的备份命令很直接：

sudo gitlab-backup create

但这里有个大坑：很多人以为备份了 GitLab 就万事大吉，其实必须同时备份/etc/gitlab/gitlab.rb配置文件、以及存储中的 SSH 主机密钥。没有配置文件，恢复出来的 GitLab 完全不是原来的样子。

恢复操作大致是：安装相同版本的 GitLab → 恢复配置 → 执行sudo gitlab-backup restore。整个过程依赖版本一致性，所以恢复前一定要确认新旧版本对应得上。

我的备份策略：

• 每天凌晨执行gitlab-backup create；
• 备份文件自动同步到异地对象存储；
• 每季度做一次恢复演练，确认备份不是"心理安慰"。

6.5 账号审批和各种登录报错的简版排查

最后简单处理几个热搜里经常出现的登录报错：

7. 到底怎么选：一张决策表加上我的个人建议

7.1 不同团队类型的选型参考

我用一张表把结论整理出来，方便各位直接对号入座：

7.2 我在实际选型中的体会

项目做下来，我的判断是：Gitee 和极狐GitLab 不是同一赛道上的竞品，不应该简单地说"谁比谁强"。Gitee 更擅长解决个人和小队的托管与协作需求，极狐GitLab 则是"把 GitLab 搬到国内来"这件事做得最到位的一个选项。

如果你现在的痛点是"GitLab 拉不动、升级慢、没人管、功能虽然多但用不上"，那 Gitee 可能已经够了，不必无脑上一个企业版花钱。如果你的痛点是"我们真的需要 GitLab 那套 CI/CD 和权限体系，只是不想再受网络和技术支持的折磨"，那极狐GitLab 会更对路。

这就像一个工具箱里不能只有一把锤子，合适就是最好。看团队规模、看合规要求、看预算、看运维能力，把这些想清楚了，选型自然就有答案。