今年帮一个做轨道交通配套软件的朋友团队做过一次代码仓选型。他们因为信创要求整个研发网从原本依赖公网 GitHub 的方式切到了隔离内网所有研发活动都不允许出网。第一步还没开始迁代码负责基础架构的同学就卡在了“本地代码仓管理平台怎么选”这个问题上。一开始我也觉得这不是现成答案吗GitLab 拉下来不就行了吗。真做起来才发现信创内网这个前提把很多在公网环境里成立的经验全部推翻了代码资产要从托管在别人服务上变成真正由自己掌控这个“自主可控”的过程远比想象中复杂。这篇文章就把这套选型方法、踩过的坑以及一个可以直接复用的评估框架完整整理出来。内容不只是聊 GitLab 和 Gitea 怎么选更多是讲清楚在内网隔离、国产化硬件、合规审计这些约束之下本地代码仓管理平台到底应该按什么逻辑来选。1. 信创内网下的代码仓选型先看清约束再谈功能很多人选型一上来就打开功能对比表看支持多少种权限模型、能不能做 MR 审批、有没有 CI/CD 集成。这些当然重要但在信创内网环境里有一堆约束条件排在功能前面。这些约束如果没想清楚后面部署完才发现跑不起来或者合规上不过关返工成本极高。1.1 隔离网络改变了哪些“默认假设”互联网环境下选代码仓默认假设是不缺软件源、不缺镜像、不缺文档缺什么直接apt install或者拉镜像就行。内网环境最大的不同是所有这些东西都需要你先准备好再搬进去。拿我这次遇到的情况举例他们的研发网是物理隔离的服务器不能访问外网也不能通过任何方式借用办公网的通道。这就意味着代码仓平台本身的安装包、依赖组件比如 Java 运行时、Node 运行库、Ruby 依赖都要提前下载好再拷贝进去后续如果需要给平台打补丁、升级小版本同样要走离线流程开发机上的 Maven、npm、pip 依赖也要在内网先搭好私有制品库不然开发根本没法推进。这些约束直接影响了平台选型安装越简单、外部依赖越少的方案在离线环境下越占优。比如 Gitea 是一个 Go 仓库静态编译出来的单二进制文件拷贝进去就能跑几乎不需要考虑依赖问题。而 GitLab 走 Omnibus 安装包本身依赖 PostgreSQL、Redis、Nginx 等一堆组件离线安装的准备工作量完全不是一个量级。这不是说 GitLab 不行而是你要提前接受它的运维成本。提示内网选型之前第一件事不是对比功能而是做一次“离线安装预演”。把目标平台的安装包、依赖清单全部下载好尝试在一台内网测试机上完成一次干净安装。这一步能筛掉一半方案。1.2 国产CPU和操作系统带来的兼容性清单信创环境里服务器和终端的 CPU、操作系统已经不是默认的 x86_64 CentOS 了。飞腾ARM 架构、鲲鹏ARM 架构、龙芯MIPS/LoongArch 架构、海光x86 兼容、兆芯x86 兼容这些 CPU 都可能在你的环境里出现操作系统则是麒麟、统信 UOS 这类国产发行版为主。代码仓平台的安装包里有没有对应架构的预编译版本直接决定了你能不能顺利装上去。这一点上各平台差异非常大二进制分发的平台Gitea、Gogs 这类基于 Go 的对各种 CPU 架构的支持通常很全官方直接提供arm64、amd64、loong64等预编译包基于 Java 的平台Gerrit、GitBlit依赖 JVM理论上跨架构能力最强但前提是你的内网里有对应架构的 JDK 可用基于 Ruby 的 GitLab官方 Omnibus 包主要针对 x86_64 和 aarch64 做了适配龙芯这类小众架构基本不要指望官方包只能自己编译那个工程量……我只能说慎重。另外操作系统层面的坑比架构更多。很多国产 Linux 发行版的内核版本较新但用户态工具链和常见的 CentOS/Ubuntu 习惯不太一样。比如在麒麟 V10 上某些依赖库名称不同、路径不同GitLab 的安装脚本可能会在检测系统版本时卡住。相对而言静态编译的单二进制程序受操作系统影响最小这也是它在信创环境里更受欢迎的核心原因。1.3 自主可控可以落到四个验收维度“自主可控”这个词听起来像口号但在代码仓选型里它是可以拆成可验收指标的。我习惯把它拆成四层每一层都有对应的判断标准可控维度要回答的问题验收方式数据主权代码、历史提交、评论、构建记录全部存在哪里谁能导出、谁能删库查数据库连接配置、备份策略、管理后台权限供应链可控平台本身和它的第三方依赖还有开源性吗没有上游支持还能不能持续运行拉取完整依赖清单核对许可证和来源授权可持续商业产品的授权条款有没有锁定期续费价格能不能接受换平台时数据能否平滑迁出看采购合同和数据导出接口二次开发可控遇到 Bug 或者要增加内部功能团队能不能改源码、扩展 API看源码开放程度、API 完备程度、插件机制这四个维度都满足才叫自主可控。很多时候我们觉得选了一个开源软件就等于自主可控了但举个例子如果团队里没人懂 RubyGitLab 出了问题只能干瞪眼等社区解答那它在“二次开发可控”这一维度上就不合格。这个结论没有对错只看你跟团队的实际情况匹配不匹配。2. 主流本地代码仓平台能力边界与信创适配实际体验理清约束条件之后再来看主流的本地代码仓管理平台视角就不一样了。我不会从“谁最强”出发而是从“谁在哪类环境里最合适”出发。下面这几个平台是我在实际选型中用过或见过的优缺点相对清晰。2.1 GitLab 私有化部署功能上限高但资源与依赖同样高GitLab 在企业里几乎是事实标准。权限模型精细、内置 CI/CD、支持 MR 审批、有完整的 Webhook 和 API团队从 GitHub 迁过来几乎无感知。如果内网环境是 x86_64 服务器团队也有专人维护基础设施GitLab 私有化部署绝对是一条稳妥路线。但我说句实在话GitLab 的“重”在信创内网里会被放大很多倍。首先是硬件官方推荐配置 4 核 4GB 内存只是起步跑起来之后光是 Sidekiq后台任务、Prometheus 监控、GitalyGit 存储这几个进程就能吃掉不少内存。我做过的项目里一台 8 核 16GB 的服务器跑 GitLab同时承载 50 人团队日常使用压力不小。如果是 200 人以上团队单机根本扛不住需要拆分组件部署那运维复杂度直接上升一个台阶。其次是依赖Omnibus 包虽然把 PostgreSQL、Redis、Nginx 这些都捆绑了但离线安装时它还会检测系统依赖、尝试安装一些基础包。我遇到过在麒麟 V10 上安装 GitLab Omnibus 时因为缺少某个系统库导致gitlab-ctl reconfigure反复失败的。后来是手动补齐了依赖绕过检测才装好。这种问题在公网环境几秒钟就能解决在内网里可能就是半天时间。然后是信创目录适配问题。如果单位明确要求所有软件必须进入信创产品目录GitLab 的开源社区版很难进入这个体系而 GitLab 的商业版包括极狐版在信创合规上的适应性也因项目而异。这点要做政府采购或国企项目时尤其敏感必须提前跟清单核对。2.2 Gitea轻量级的真香与需要妥协的地方Gitea 是我近两年在信创内网里最常推荐的方案原因很简单它真正踩中了内网环境的痛点。Gitea 是 Go 语言写成的单二进制程序官方发布页直接提供 Linux amd64、arm64、loong64 等多种版本下载下来加执行权限就能跑。它内置 SQLite 作为默认数据库也就是说在极小规模比如 50 人以内场景下你连单独的数据库都不用装一个进程、一个数据文件就是一套代码仓。这对离线部署极其友好。功能上 Gitea 并不是“玩具”。它支持组织和仓库的精细权限控制Owner、Write、Read 三级权限支持分支保护Pull Request / 合并请求评审流程可以设置强制评审人数Webhook 与 API能和 Jenkins 等 CI 工具对接内置仓库迁移工具支持从 GitLab、GitHub、Bitbucket 等平台直接导入仓库和基础元数据内置 LFSLarge File Storage支持可以管理大文件。那它要妥协的是什么一个是内置 CI/CDGitea Actions在生态丰富度和稳定性和 GitLab CI 有差距插件、内置镜像、文档支持目前都还在追赶另一个是超大规模场景下的性能表现官方建议单实例支持到数百人没问题但上千人同时高频使用、仓库量大到数万级别时它的架构相对单一扩展性不如 GitLab 那套组件化设计。在信创环境里Gitea 还有个隐藏优点它作为开源社区项目不跟任何商业公司绑定数据迁移、二次开发都是可控的。配合它的中文社区和文档国内团队接手门槛很低。如果你是 50 到 200 人规模的团队我建议把它放在备选清单的第一位。2.3 Gerrit 和 GitBlit评审优先的小众路线Gerrit 是 Google 开源的一套代码评审系统在开源社区和部分对代码质量管控要求极高的团队里很受欢迎。它的特色是“先评审、后合入”的严格流程每个提交都必须通过 Review 才能进主干非常适合做合规审查、安全审计。但 Gerrit 在信创内网里的问题也很明显部署依赖 Java 环境和独立的数据库通常用 PostgreSQL本身还不是一个“开箱即用的代码仓平台”它的定位更偏向代码评审工具而不是仓库托管平台很多团队还需要额外搭配一个仓库平台使用。这就等于一套代码管理要维护两套系统内网里运算量虽然不是问题但维护面被拉大了。另外Gerrit 对 Git 的交互方式做了特殊扩展开发者需要使用它提供的git push origin HEAD:refs/for/master这种特殊引用格式从 GitHub 迁过来的团队需要重新适应学习成本不低。GitBlit 是更老的 Java 系方案内置了很多企业功能如权限、LDAP 集成、简单的代码浏览界面也还过得去。问题在于它的社区活跃度已经很低很多年没有大的功能更新在信创环境里遇到兼容性问题找不到人解决。除非团队有很深的 Java 功底、并且存量系统就是基于它改造的否则我不建议新建项目选它。2.4 国产商用代码仓自主和包装不能划等号现在市面上也有不少国产商用代码仓产品主打“信创适配”“本地化部署”。有些产品本身架构很完整提供了 GitLab 同等级的权限管控、审计日志、国产化数据库适配并且做了等保合规预评估对很多政企单位来说这比开源平台省心得多。但我在选型里会特别警惕“包装自主”的现象。有些商用产品是基于开源 Gitea 或 GitLab 改的换了个皮加了些管理功能就挂上自主可控的名号。这类产品不是不能用而是要搞明白三个问题它使用的是哪个开源版本作为底座如果是老旧版本那可能带着已知安全漏洞它对底层代码的 fork 分支持续跟进上游吗如果长期不跟以后出安全补丁只能等厂商它的数据格式和上游兼容吗如果哪天不续费了数据能不能顺利迁到别的平台我的原则是如果团队技术能力强直接选开源 Gitea 或 GitLab自己做适配如果团队更需要厂商兜底和合规材料选国产商用产品时要把“底座版本、维护周期、数据可迁移性”写进合同验收条款。下面用一张表把几个方案的定位做对比方便你做粗略筛选平台部署复杂度资源占用信创适配难度评审/权限能力二次开发难度典型适用规模GitLab 私有化高高中到高强高100人以上有运维团队Gitea低低低中低200人以内轻量快速Gogs极低极低低中低50人以内最小化场景Gerrit中中中评审极强中评审管控优先的团队GitBlit低中低中中中存量Java系统延续国产商用中视产品而定低已适配中到强视开放程度而定需合规材料政企单位注意这张表只能用于初筛。真正定版之前一定要在自己内网环境做一轮功能验证和压力测试这东西别人替代不了。3. 从需求出发的两级打分模型选型不是比参数既然方案各有优劣那怎么在同一标准下比较我给朋友团队做的是一套“两级打分模型”先梳理需求清单再对每个需求设定权重最后让备选平台逐项打分。这个模型不追求绝对客观但能逼着团队把所有关心的问题都摆到桌面上。3.1 先列需求清单代码仓管理平台的职责边界代码仓平台在团队里承担的职责往往比“存代码”多得多。我建议团队围绕下面几条主线梳理需求代码托管支持 Git 标准协议、仓库数量上限、单仓大小、LFS 支持情况权限与合规用户认证方式LDAP/LADP、CAS、企业微信集成、密钥管理、分支保护、审计日志粒度协作与评审MR/PR 工作流、强制评审规则、代码机器人、评论与通知工具链集成Webhook、OpenAPI、与 CI/CD 系统的对接、与内部研发平台的集成数据生命周期备份恢复、归档策略、代码导出控制、仓库迁移能力信创落地是否支持目标 CPU/OS、是否适配单位要求的国产数据库、有无通过等保定级相关配合。把这些需求列出来后再给每条需求打“必须满足 / 应该满足 / 可以缓一缓”的标签。这比直接进入品牌比较要靠谱得多。3.2 指标权重设计什么分数应该给得高权重没有统一答案不同单位关注点不一样。但我给政企研发团队做选型时一般建议采用这样一组权重作为起点评分维度建议权重说明信创环境适配性25%能不能在目标 CPU/OS/数据库上跑得起来功能与协作能力25%评审、权限、API、CI 集成等日常开发体验部署运维成本20%离线安装难度、备份方案、故障恢复、监控安全合规能力20%审计日志、数据加密、权限细粒度、等保配合长期演进与供应链10%许可证、社区活跃度、是否可持续升级这个权重对“稳字当头”的单位是合理的。如果是一个互联网小型创业团队信创适配性不会排在这么前部署运维成本可能反而是首位。3.3 一次真实推演三个方案打分后的选择我拿当时做的一次推演做例子。团队规模约 60 人现有代码仓库约 80 个最大的仓库接近 3GB服务器是海光 x86 架构 麒麟 V10数据库强制要求用达梦等保三级是硬指标。先看候选方案对硬性条件的满足情况GitLab能适配麒麟但达梦不在官方支持列表里要额外开发存储适配层工程量大Gitea能适配麒麟原装用 SQLite/MySQL/PostgreSQL对达梦也没有现成适配需要做存储层替换或折中方案国产商用平台直接支持海光和达梦软件证书齐全等保配合有专门团队支持。这个局面上前两个方案虽然功能可能更好但“信创环境适配性”这个 25% 的权重项得分很低总分会瞬间被国产商用平台追平甚至反超。这也是“选择最优还是选择最合适”的典型场景。最终他们选了国产商用平台但我在合同里加了“数据可迁移性”验收项确保未来即使换平台也能把历史数据完整导出来。提示打分模型的意义不是算出唯一正确答案而是把团队里每个人的隐性顾虑显性化。有一次打分会议上评审分数不是关键关键是有人提出“我们没有 Ruby 运维经验”这个之前放在台面下的担忧直接改变了结论。4. 从选定到落地部署迁移中真正卡人的细节选型结束只算完成了三分之一后面部署、迁移、调优才是大头。这一节我把内网部署过程中的关键动作和容易踩的坑都列出来尤其是离线环境下那几步。4.1 离线安装依赖的“黑洞”与处理路径无论你最终选什么平台离线安装之前都建议先看一眼它的安装脚本到底要做哪些事情。我遇到最典型的坑是 GitLab Omnibus 安装时要用公网源更新系统软件包内网里直接报超时。解决路径有两种在能上网的机器上把.deb或.rpm包及所有依赖下载齐全然后拷贝进内网用dpkg -i或rpm -Uvh逐个安装如果平台支持容器化部署就提前下载好 Docker 镜像注意导出和导入命令docker save/docker load这种方法虽然镜像体积大但依赖封闭在镜像里反而相对省心。Gitea 这类单二进制就没这些烦恼。下载二进制包后给它附上执行权限设置一个普通用户运行一个命令搞定# 以 gitea 用户运行并指定配置文件 sudo mkdir -p /var/lib/gitea sudo chown gitea:gitea /var/lib/gitea sudo -u gitea ./gitea web --config /etc/gitea/app.ini我在麒麟 V10 上跑 Gitea 遇到过一次动态链接库的提示检查后确认是缺少libc相关模块将二进制换成官方提供的 musl 静态版本后问题消失。Go 的二进制的优点在这里体现得很明显不依赖系统库拷贝到任意架构的机器上都能跑。4.2 存量仓库迁移保历史、保权限、保习惯从旧的代码托管平台迁到新的本地代码仓最怕的不是丢代码而是丢历史、丢权限、丢团队使用习惯。代码本身迁移最简单一条命令就能把远程仓库完整镜像拉下来再推上去git clone --mirror https://old-platform/group/repo.git cd repo.git git remote set-url origin gitnew-platform:group/repo.git git push --mirror origin--mirror会把所有分支、标签、引用全部带上保证 Git 历史不丢。但如果想把 MR/PR 记录、评论、评审历史也迁过去就要靠平台自带的迁移工具了。Gitea 的管理后台直接支持从 GitLab、GitHub 导入仓库及部分元数据GitLab 则可以用 group 迁移接口来搬。权限和习惯这两块是更容易被忽略的。老平台里一个项目的成员可能分布在三四个小组里权限级别各不相同到了新平台如果重新手工建一遍很容易漏配。我建议把权限矩阵先在 Excel 或各类表格里整理出来再按批次导入。团队使用习惯方面最有效的方式是在新平台正式上线前先拉两三个核心开发小组用一周收集反馈把新平台的 Webhook 通知地址、代码评审规则、默认分支保护策略调好后再全面铺开。这里还要留意自己的主机名/域名规划。代码仓平台的地址开发人员要配进 Git remote还要写入各自动化工具的配置。一旦上线后改名改动面会很大。所以前期要跟网络管理员确认好给代码仓分配固定的内网域名和证书尽量避免用 IP 地址直接访问不然以后换机器就会大量修改 clone 地址。4.3 上线运行后立刻要调整的配置项上线不是终点。根据我这几年的经验代码仓平台部署完成后有几个配置项务必要立刻调整仓库可见性与默认权限新平台默认创建仓库时权限往往是对所有人可见的。要在全局设置里把默认可见性改为私有或者仅项目成员可见防止内部代码被跨部门同事随意浏览。备份策略代码仓平台是整个研发团队的命根子数据丢了不是小事。Gitea 自带gitea dump命令GitLab 有gitlab-backup create两者都可以配合 cron 做定时备份。Webhook 与通知把代码推送、PR 创建、评审通过这些事件接进内部的即时消息系统让开发人员在新平台上能第一时间感知变化。如果不做这一步很多人会下意识回到旧平台看动态。仓库命名规范与分组策略趁迁移刚开始就定好群组/组织结构按业务线或者服务划分不然两三个月后仓库一多就会变成一锅粥。下面的定时任务脚本是我在 Gitea 环境里常用的#!/bin/bash # 每日凌晨2点执行Gitea全量备份保留最近30天 DATE$(date %Y%m%d%H%M) /usr/local/gitea/gitea dump \ --config /etc/gitea/app.ini \ --file /backup/gitea-$DATE.zip \ --type zip find /backup -name gitea-*.zip -mtime 30 -delete用 cron 挂上备份就自动跑了。内网环境里我强烈建议至少保留一份异地副本就是同一个备份文件拷贝到另一台物理机或者存储上。毕竟代码仓平台唯一的数据来源就是这一份库没有异地备份遇到机房级故障就彻底傻眼了。5. 自主可控不是一次验收是持续维护的管理台账选型、部署、迁移做完之后很多人觉得“自主可控”这件事已经结束了。我的看法完全相反真正的自主可控是通过后面几个季度的持续维护才逐步建立起来的。选对平台只是起点后面管理跟不上照样失控。5.1 许可证与供应链风险自查开源虽然有“免费”“开放”的标签但它的许可证规则很多。一个平台本身是 MIT 或者 Apache 2.0 许可这不代表它依赖的所有第三方库都是同一种许可。有些库可能是 GPL 协议存在传染性有些库可能是商业授权。这些问题平时不显眼做信创合规验收时却很容易被揪出来。我建议在上线后做一次“供应链盘点”把代码仓平台运行时使用到的第三方组件列出来逐个核对许可证类型确认没有与单位使用场景冲突的条款记录每个组件的版本号和来源方便后续安全公告出来后做排查。这个动作做一次并不难胜在它可以形成一份“软件物料清单”。以后平台升级时增量对比这份清单就能快速评估升级带来的影响。5.2 备份、审计与代码资产盘点代码资产不只是代码本身还包括技术文档、审查记录、问题跟踪、构建配置这些东西。所以我在项目里会要求每个季度做一次代码资产盘点明确当前有多少活跃仓库、多少僵尸仓库、谁负责维护、哪些仓库的数据导出来可以在别处恢复。安全审计层面重点要盯几个动作谁在什么时间 clone 过哪个仓库谁导出过代码包谁调整过仓库权限这些操作在主流代码仓平台里都有审计日志问题是日志默认不一定开全也没人定期看。我建议把审计日志导出到一个独立存储中保留时间不低于合规要求常常要求半年以上一旦有人员变动或者安全检查这些记录就能起大作用。5.3 与周边研发体系的联动避免“有仓无管”代码仓平台只是研发工具链里的一个环节。要让它真正发挥价值还要跟周边系统做好联动和制品仓库联动代码构建出来的软件包进入内网私有制品库形成从源码到二进制交付物的链条和 CI/CD 联动代码推送后自动触发构建和部署让内网开发流程闭环和需求/缺陷系统联动提交信息关联需求单号让代码变更可追溯。如果这些联动迟迟不做代码仓平台就只是一个“代码网盘”体现不了研发过程管理价值。我在一个项目里见过代码仓选了 Gitea半年后开发人员还是在用网盘传压缩包原因是 Webhook 没接 CI、API 没对接需求系统平台形同虚设。所以选型完成后这些周边工具的集成方案也要同步排期。最后再分享一个我在迁移过程中的小技巧把一个平台的 wiki、Readme、Issue 这些“非代码资产”也纳入迁移清单。很多团队迁代码很顺利但历史文档和问题记录留在老平台里后面要找资料还得开旧系统这其实是隐性成本。迁移时顺手把这些内容也搬过去哪怕只是归档成静态文件也比散落在旧系统里强。信创内网下的代码仓选型本质上不是一次技术选型而是一次研发数字化底座的重新搭建。选什么样的平台决定了未来几年团队在上面怎么协作、怎么沉淀、怎么出活。把这套方法带回去结合自己团队的情况过一遍会比什么都拿“最好”两个字来定义靠谱得多。 信创内网代码仓选型：从GitLab到Gitea的自主可控实践
今年帮一个做轨道交通配套软件的朋友团队做过一次代码仓选型。他们因为信创要求整个研发网从原本依赖公网 GitHub 的方式切到了隔离内网所有研发活动都不允许出网。第一步还没开始迁代码负责基础架构的同学就卡在了“本地代码仓管理平台怎么选”这个问题上。一开始我也觉得这不是现成答案吗GitLab 拉下来不就行了吗。真做起来才发现信创内网这个前提把很多在公网环境里成立的经验全部推翻了代码资产要从托管在别人服务上变成真正由自己掌控这个“自主可控”的过程远比想象中复杂。这篇文章就把这套选型方法、踩过的坑以及一个可以直接复用的评估框架完整整理出来。内容不只是聊 GitLab 和 Gitea 怎么选更多是讲清楚在内网隔离、国产化硬件、合规审计这些约束之下本地代码仓管理平台到底应该按什么逻辑来选。1. 信创内网下的代码仓选型先看清约束再谈功能很多人选型一上来就打开功能对比表看支持多少种权限模型、能不能做 MR 审批、有没有 CI/CD 集成。这些当然重要但在信创内网环境里有一堆约束条件排在功能前面。这些约束如果没想清楚后面部署完才发现跑不起来或者合规上不过关返工成本极高。1.1 隔离网络改变了哪些“默认假设”互联网环境下选代码仓默认假设是不缺软件源、不缺镜像、不缺文档缺什么直接apt install或者拉镜像就行。内网环境最大的不同是所有这些东西都需要你先准备好再搬进去。拿我这次遇到的情况举例他们的研发网是物理隔离的服务器不能访问外网也不能通过任何方式借用办公网的通道。这就意味着代码仓平台本身的安装包、依赖组件比如 Java 运行时、Node 运行库、Ruby 依赖都要提前下载好再拷贝进去后续如果需要给平台打补丁、升级小版本同样要走离线流程开发机上的 Maven、npm、pip 依赖也要在内网先搭好私有制品库不然开发根本没法推进。这些约束直接影响了平台选型安装越简单、外部依赖越少的方案在离线环境下越占优。比如 Gitea 是一个 Go 仓库静态编译出来的单二进制文件拷贝进去就能跑几乎不需要考虑依赖问题。而 GitLab 走 Omnibus 安装包本身依赖 PostgreSQL、Redis、Nginx 等一堆组件离线安装的准备工作量完全不是一个量级。这不是说 GitLab 不行而是你要提前接受它的运维成本。提示内网选型之前第一件事不是对比功能而是做一次“离线安装预演”。把目标平台的安装包、依赖清单全部下载好尝试在一台内网测试机上完成一次干净安装。这一步能筛掉一半方案。1.2 国产CPU和操作系统带来的兼容性清单信创环境里服务器和终端的 CPU、操作系统已经不是默认的 x86_64 CentOS 了。飞腾ARM 架构、鲲鹏ARM 架构、龙芯MIPS/LoongArch 架构、海光x86 兼容、兆芯x86 兼容这些 CPU 都可能在你的环境里出现操作系统则是麒麟、统信 UOS 这类国产发行版为主。代码仓平台的安装包里有没有对应架构的预编译版本直接决定了你能不能顺利装上去。这一点上各平台差异非常大二进制分发的平台Gitea、Gogs 这类基于 Go 的对各种 CPU 架构的支持通常很全官方直接提供arm64、amd64、loong64等预编译包基于 Java 的平台Gerrit、GitBlit依赖 JVM理论上跨架构能力最强但前提是你的内网里有对应架构的 JDK 可用基于 Ruby 的 GitLab官方 Omnibus 包主要针对 x86_64 和 aarch64 做了适配龙芯这类小众架构基本不要指望官方包只能自己编译那个工程量……我只能说慎重。另外操作系统层面的坑比架构更多。很多国产 Linux 发行版的内核版本较新但用户态工具链和常见的 CentOS/Ubuntu 习惯不太一样。比如在麒麟 V10 上某些依赖库名称不同、路径不同GitLab 的安装脚本可能会在检测系统版本时卡住。相对而言静态编译的单二进制程序受操作系统影响最小这也是它在信创环境里更受欢迎的核心原因。1.3 自主可控可以落到四个验收维度“自主可控”这个词听起来像口号但在代码仓选型里它是可以拆成可验收指标的。我习惯把它拆成四层每一层都有对应的判断标准可控维度要回答的问题验收方式数据主权代码、历史提交、评论、构建记录全部存在哪里谁能导出、谁能删库查数据库连接配置、备份策略、管理后台权限供应链可控平台本身和它的第三方依赖还有开源性吗没有上游支持还能不能持续运行拉取完整依赖清单核对许可证和来源授权可持续商业产品的授权条款有没有锁定期续费价格能不能接受换平台时数据能否平滑迁出看采购合同和数据导出接口二次开发可控遇到 Bug 或者要增加内部功能团队能不能改源码、扩展 API看源码开放程度、API 完备程度、插件机制这四个维度都满足才叫自主可控。很多时候我们觉得选了一个开源软件就等于自主可控了但举个例子如果团队里没人懂 RubyGitLab 出了问题只能干瞪眼等社区解答那它在“二次开发可控”这一维度上就不合格。这个结论没有对错只看你跟团队的实际情况匹配不匹配。2. 主流本地代码仓平台能力边界与信创适配实际体验理清约束条件之后再来看主流的本地代码仓管理平台视角就不一样了。我不会从“谁最强”出发而是从“谁在哪类环境里最合适”出发。下面这几个平台是我在实际选型中用过或见过的优缺点相对清晰。2.1 GitLab 私有化部署功能上限高但资源与依赖同样高GitLab 在企业里几乎是事实标准。权限模型精细、内置 CI/CD、支持 MR 审批、有完整的 Webhook 和 API团队从 GitHub 迁过来几乎无感知。如果内网环境是 x86_64 服务器团队也有专人维护基础设施GitLab 私有化部署绝对是一条稳妥路线。但我说句实在话GitLab 的“重”在信创内网里会被放大很多倍。首先是硬件官方推荐配置 4 核 4GB 内存只是起步跑起来之后光是 Sidekiq后台任务、Prometheus 监控、GitalyGit 存储这几个进程就能吃掉不少内存。我做过的项目里一台 8 核 16GB 的服务器跑 GitLab同时承载 50 人团队日常使用压力不小。如果是 200 人以上团队单机根本扛不住需要拆分组件部署那运维复杂度直接上升一个台阶。其次是依赖Omnibus 包虽然把 PostgreSQL、Redis、Nginx 这些都捆绑了但离线安装时它还会检测系统依赖、尝试安装一些基础包。我遇到过在麒麟 V10 上安装 GitLab Omnibus 时因为缺少某个系统库导致gitlab-ctl reconfigure反复失败的。后来是手动补齐了依赖绕过检测才装好。这种问题在公网环境几秒钟就能解决在内网里可能就是半天时间。然后是信创目录适配问题。如果单位明确要求所有软件必须进入信创产品目录GitLab 的开源社区版很难进入这个体系而 GitLab 的商业版包括极狐版在信创合规上的适应性也因项目而异。这点要做政府采购或国企项目时尤其敏感必须提前跟清单核对。2.2 Gitea轻量级的真香与需要妥协的地方Gitea 是我近两年在信创内网里最常推荐的方案原因很简单它真正踩中了内网环境的痛点。Gitea 是 Go 语言写成的单二进制程序官方发布页直接提供 Linux amd64、arm64、loong64 等多种版本下载下来加执行权限就能跑。它内置 SQLite 作为默认数据库也就是说在极小规模比如 50 人以内场景下你连单独的数据库都不用装一个进程、一个数据文件就是一套代码仓。这对离线部署极其友好。功能上 Gitea 并不是“玩具”。它支持组织和仓库的精细权限控制Owner、Write、Read 三级权限支持分支保护Pull Request / 合并请求评审流程可以设置强制评审人数Webhook 与 API能和 Jenkins 等 CI 工具对接内置仓库迁移工具支持从 GitLab、GitHub、Bitbucket 等平台直接导入仓库和基础元数据内置 LFSLarge File Storage支持可以管理大文件。那它要妥协的是什么一个是内置 CI/CDGitea Actions在生态丰富度和稳定性和 GitLab CI 有差距插件、内置镜像、文档支持目前都还在追赶另一个是超大规模场景下的性能表现官方建议单实例支持到数百人没问题但上千人同时高频使用、仓库量大到数万级别时它的架构相对单一扩展性不如 GitLab 那套组件化设计。在信创环境里Gitea 还有个隐藏优点它作为开源社区项目不跟任何商业公司绑定数据迁移、二次开发都是可控的。配合它的中文社区和文档国内团队接手门槛很低。如果你是 50 到 200 人规模的团队我建议把它放在备选清单的第一位。2.3 Gerrit 和 GitBlit评审优先的小众路线Gerrit 是 Google 开源的一套代码评审系统在开源社区和部分对代码质量管控要求极高的团队里很受欢迎。它的特色是“先评审、后合入”的严格流程每个提交都必须通过 Review 才能进主干非常适合做合规审查、安全审计。但 Gerrit 在信创内网里的问题也很明显部署依赖 Java 环境和独立的数据库通常用 PostgreSQL本身还不是一个“开箱即用的代码仓平台”它的定位更偏向代码评审工具而不是仓库托管平台很多团队还需要额外搭配一个仓库平台使用。这就等于一套代码管理要维护两套系统内网里运算量虽然不是问题但维护面被拉大了。另外Gerrit 对 Git 的交互方式做了特殊扩展开发者需要使用它提供的git push origin HEAD:refs/for/master这种特殊引用格式从 GitHub 迁过来的团队需要重新适应学习成本不低。GitBlit 是更老的 Java 系方案内置了很多企业功能如权限、LDAP 集成、简单的代码浏览界面也还过得去。问题在于它的社区活跃度已经很低很多年没有大的功能更新在信创环境里遇到兼容性问题找不到人解决。除非团队有很深的 Java 功底、并且存量系统就是基于它改造的否则我不建议新建项目选它。2.4 国产商用代码仓自主和包装不能划等号现在市面上也有不少国产商用代码仓产品主打“信创适配”“本地化部署”。有些产品本身架构很完整提供了 GitLab 同等级的权限管控、审计日志、国产化数据库适配并且做了等保合规预评估对很多政企单位来说这比开源平台省心得多。但我在选型里会特别警惕“包装自主”的现象。有些商用产品是基于开源 Gitea 或 GitLab 改的换了个皮加了些管理功能就挂上自主可控的名号。这类产品不是不能用而是要搞明白三个问题它使用的是哪个开源版本作为底座如果是老旧版本那可能带着已知安全漏洞它对底层代码的 fork 分支持续跟进上游吗如果长期不跟以后出安全补丁只能等厂商它的数据格式和上游兼容吗如果哪天不续费了数据能不能顺利迁到别的平台我的原则是如果团队技术能力强直接选开源 Gitea 或 GitLab自己做适配如果团队更需要厂商兜底和合规材料选国产商用产品时要把“底座版本、维护周期、数据可迁移性”写进合同验收条款。下面用一张表把几个方案的定位做对比方便你做粗略筛选平台部署复杂度资源占用信创适配难度评审/权限能力二次开发难度典型适用规模GitLab 私有化高高中到高强高100人以上有运维团队Gitea低低低中低200人以内轻量快速Gogs极低极低低中低50人以内最小化场景Gerrit中中中评审极强中评审管控优先的团队GitBlit低中低中中中存量Java系统延续国产商用中视产品而定低已适配中到强视开放程度而定需合规材料政企单位注意这张表只能用于初筛。真正定版之前一定要在自己内网环境做一轮功能验证和压力测试这东西别人替代不了。3. 从需求出发的两级打分模型选型不是比参数既然方案各有优劣那怎么在同一标准下比较我给朋友团队做的是一套“两级打分模型”先梳理需求清单再对每个需求设定权重最后让备选平台逐项打分。这个模型不追求绝对客观但能逼着团队把所有关心的问题都摆到桌面上。3.1 先列需求清单代码仓管理平台的职责边界代码仓平台在团队里承担的职责往往比“存代码”多得多。我建议团队围绕下面几条主线梳理需求代码托管支持 Git 标准协议、仓库数量上限、单仓大小、LFS 支持情况权限与合规用户认证方式LDAP/LADP、CAS、企业微信集成、密钥管理、分支保护、审计日志粒度协作与评审MR/PR 工作流、强制评审规则、代码机器人、评论与通知工具链集成Webhook、OpenAPI、与 CI/CD 系统的对接、与内部研发平台的集成数据生命周期备份恢复、归档策略、代码导出控制、仓库迁移能力信创落地是否支持目标 CPU/OS、是否适配单位要求的国产数据库、有无通过等保定级相关配合。把这些需求列出来后再给每条需求打“必须满足 / 应该满足 / 可以缓一缓”的标签。这比直接进入品牌比较要靠谱得多。3.2 指标权重设计什么分数应该给得高权重没有统一答案不同单位关注点不一样。但我给政企研发团队做选型时一般建议采用这样一组权重作为起点评分维度建议权重说明信创环境适配性25%能不能在目标 CPU/OS/数据库上跑得起来功能与协作能力25%评审、权限、API、CI 集成等日常开发体验部署运维成本20%离线安装难度、备份方案、故障恢复、监控安全合规能力20%审计日志、数据加密、权限细粒度、等保配合长期演进与供应链10%许可证、社区活跃度、是否可持续升级这个权重对“稳字当头”的单位是合理的。如果是一个互联网小型创业团队信创适配性不会排在这么前部署运维成本可能反而是首位。3.3 一次真实推演三个方案打分后的选择我拿当时做的一次推演做例子。团队规模约 60 人现有代码仓库约 80 个最大的仓库接近 3GB服务器是海光 x86 架构 麒麟 V10数据库强制要求用达梦等保三级是硬指标。先看候选方案对硬性条件的满足情况GitLab能适配麒麟但达梦不在官方支持列表里要额外开发存储适配层工程量大Gitea能适配麒麟原装用 SQLite/MySQL/PostgreSQL对达梦也没有现成适配需要做存储层替换或折中方案国产商用平台直接支持海光和达梦软件证书齐全等保配合有专门团队支持。这个局面上前两个方案虽然功能可能更好但“信创环境适配性”这个 25% 的权重项得分很低总分会瞬间被国产商用平台追平甚至反超。这也是“选择最优还是选择最合适”的典型场景。最终他们选了国产商用平台但我在合同里加了“数据可迁移性”验收项确保未来即使换平台也能把历史数据完整导出来。提示打分模型的意义不是算出唯一正确答案而是把团队里每个人的隐性顾虑显性化。有一次打分会议上评审分数不是关键关键是有人提出“我们没有 Ruby 运维经验”这个之前放在台面下的担忧直接改变了结论。4. 从选定到落地部署迁移中真正卡人的细节选型结束只算完成了三分之一后面部署、迁移、调优才是大头。这一节我把内网部署过程中的关键动作和容易踩的坑都列出来尤其是离线环境下那几步。4.1 离线安装依赖的“黑洞”与处理路径无论你最终选什么平台离线安装之前都建议先看一眼它的安装脚本到底要做哪些事情。我遇到最典型的坑是 GitLab Omnibus 安装时要用公网源更新系统软件包内网里直接报超时。解决路径有两种在能上网的机器上把.deb或.rpm包及所有依赖下载齐全然后拷贝进内网用dpkg -i或rpm -Uvh逐个安装如果平台支持容器化部署就提前下载好 Docker 镜像注意导出和导入命令docker save/docker load这种方法虽然镜像体积大但依赖封闭在镜像里反而相对省心。Gitea 这类单二进制就没这些烦恼。下载二进制包后给它附上执行权限设置一个普通用户运行一个命令搞定# 以 gitea 用户运行并指定配置文件 sudo mkdir -p /var/lib/gitea sudo chown gitea:gitea /var/lib/gitea sudo -u gitea ./gitea web --config /etc/gitea/app.ini我在麒麟 V10 上跑 Gitea 遇到过一次动态链接库的提示检查后确认是缺少libc相关模块将二进制换成官方提供的 musl 静态版本后问题消失。Go 的二进制的优点在这里体现得很明显不依赖系统库拷贝到任意架构的机器上都能跑。4.2 存量仓库迁移保历史、保权限、保习惯从旧的代码托管平台迁到新的本地代码仓最怕的不是丢代码而是丢历史、丢权限、丢团队使用习惯。代码本身迁移最简单一条命令就能把远程仓库完整镜像拉下来再推上去git clone --mirror https://old-platform/group/repo.git cd repo.git git remote set-url origin gitnew-platform:group/repo.git git push --mirror origin--mirror会把所有分支、标签、引用全部带上保证 Git 历史不丢。但如果想把 MR/PR 记录、评论、评审历史也迁过去就要靠平台自带的迁移工具了。Gitea 的管理后台直接支持从 GitLab、GitHub 导入仓库及部分元数据GitLab 则可以用 group 迁移接口来搬。权限和习惯这两块是更容易被忽略的。老平台里一个项目的成员可能分布在三四个小组里权限级别各不相同到了新平台如果重新手工建一遍很容易漏配。我建议把权限矩阵先在 Excel 或各类表格里整理出来再按批次导入。团队使用习惯方面最有效的方式是在新平台正式上线前先拉两三个核心开发小组用一周收集反馈把新平台的 Webhook 通知地址、代码评审规则、默认分支保护策略调好后再全面铺开。这里还要留意自己的主机名/域名规划。代码仓平台的地址开发人员要配进 Git remote还要写入各自动化工具的配置。一旦上线后改名改动面会很大。所以前期要跟网络管理员确认好给代码仓分配固定的内网域名和证书尽量避免用 IP 地址直接访问不然以后换机器就会大量修改 clone 地址。4.3 上线运行后立刻要调整的配置项上线不是终点。根据我这几年的经验代码仓平台部署完成后有几个配置项务必要立刻调整仓库可见性与默认权限新平台默认创建仓库时权限往往是对所有人可见的。要在全局设置里把默认可见性改为私有或者仅项目成员可见防止内部代码被跨部门同事随意浏览。备份策略代码仓平台是整个研发团队的命根子数据丢了不是小事。Gitea 自带gitea dump命令GitLab 有gitlab-backup create两者都可以配合 cron 做定时备份。Webhook 与通知把代码推送、PR 创建、评审通过这些事件接进内部的即时消息系统让开发人员在新平台上能第一时间感知变化。如果不做这一步很多人会下意识回到旧平台看动态。仓库命名规范与分组策略趁迁移刚开始就定好群组/组织结构按业务线或者服务划分不然两三个月后仓库一多就会变成一锅粥。下面的定时任务脚本是我在 Gitea 环境里常用的#!/bin/bash # 每日凌晨2点执行Gitea全量备份保留最近30天 DATE$(date %Y%m%d%H%M) /usr/local/gitea/gitea dump \ --config /etc/gitea/app.ini \ --file /backup/gitea-$DATE.zip \ --type zip find /backup -name gitea-*.zip -mtime 30 -delete用 cron 挂上备份就自动跑了。内网环境里我强烈建议至少保留一份异地副本就是同一个备份文件拷贝到另一台物理机或者存储上。毕竟代码仓平台唯一的数据来源就是这一份库没有异地备份遇到机房级故障就彻底傻眼了。5. 自主可控不是一次验收是持续维护的管理台账选型、部署、迁移做完之后很多人觉得“自主可控”这件事已经结束了。我的看法完全相反真正的自主可控是通过后面几个季度的持续维护才逐步建立起来的。选对平台只是起点后面管理跟不上照样失控。5.1 许可证与供应链风险自查开源虽然有“免费”“开放”的标签但它的许可证规则很多。一个平台本身是 MIT 或者 Apache 2.0 许可这不代表它依赖的所有第三方库都是同一种许可。有些库可能是 GPL 协议存在传染性有些库可能是商业授权。这些问题平时不显眼做信创合规验收时却很容易被揪出来。我建议在上线后做一次“供应链盘点”把代码仓平台运行时使用到的第三方组件列出来逐个核对许可证类型确认没有与单位使用场景冲突的条款记录每个组件的版本号和来源方便后续安全公告出来后做排查。这个动作做一次并不难胜在它可以形成一份“软件物料清单”。以后平台升级时增量对比这份清单就能快速评估升级带来的影响。5.2 备份、审计与代码资产盘点代码资产不只是代码本身还包括技术文档、审查记录、问题跟踪、构建配置这些东西。所以我在项目里会要求每个季度做一次代码资产盘点明确当前有多少活跃仓库、多少僵尸仓库、谁负责维护、哪些仓库的数据导出来可以在别处恢复。安全审计层面重点要盯几个动作谁在什么时间 clone 过哪个仓库谁导出过代码包谁调整过仓库权限这些操作在主流代码仓平台里都有审计日志问题是日志默认不一定开全也没人定期看。我建议把审计日志导出到一个独立存储中保留时间不低于合规要求常常要求半年以上一旦有人员变动或者安全检查这些记录就能起大作用。5.3 与周边研发体系的联动避免“有仓无管”代码仓平台只是研发工具链里的一个环节。要让它真正发挥价值还要跟周边系统做好联动和制品仓库联动代码构建出来的软件包进入内网私有制品库形成从源码到二进制交付物的链条和 CI/CD 联动代码推送后自动触发构建和部署让内网开发流程闭环和需求/缺陷系统联动提交信息关联需求单号让代码变更可追溯。如果这些联动迟迟不做代码仓平台就只是一个“代码网盘”体现不了研发过程管理价值。我在一个项目里见过代码仓选了 Gitea半年后开发人员还是在用网盘传压缩包原因是 Webhook 没接 CI、API 没对接需求系统平台形同虚设。所以选型完成后这些周边工具的集成方案也要同步排期。最后再分享一个我在迁移过程中的小技巧把一个平台的 wiki、Readme、Issue 这些“非代码资产”也纳入迁移清单。很多团队迁代码很顺利但历史文档和问题记录留在老平台里后面要找资料还得开旧系统这其实是隐性成本。迁移时顺手把这些内容也搬过去哪怕只是归档成静态文件也比散落在旧系统里强。信创内网下的代码仓选型本质上不是一次技术选型而是一次研发数字化底座的重新搭建。选什么样的平台决定了未来几年团队在上面怎么协作、怎么沉淀、怎么出活。把这套方法带回去结合自己团队的情况过一遍会比什么都拿“最好”两个字来定义靠谱得多。