很多人第一次看到这四个名字脑子里浮现的都是不就是放代码的地方吗。真到了要给团队定平台的时候才发现GitHub、GitLab、Gerrit、GerritHub 根本不在同一个维度上打架——一个卖的是社交化协作生态一个卖的是一体化 DevOps 流水线一个把代码评审当成铁律门禁最后一个只是个桥接产物。这篇文章不站队只讲清楚各自的机制、代价和适用边界然后给你一套能直接照着走的选型逻辑和落地配置。不管你是三个人凑起来的创业小队还是要在内网搭一套带审计的代码平台看完应该都能判断自己该上哪一个、怎么搭、坑在哪。1. 先把定位掰开四个名字压根不是同类竞品1.1 GitHub生态与协作网络的中心节点GitHub 的核心资产从来不是 Git 仓库本身而是围绕仓库长出来的那张网。Pull Request 把提代码变成了一场公开讨论Issue 把需求和缺陷收进了同一条时间线Actions 让自动化直接长在仓库里再加上 Pages、Codespaces、Packages、Codes Security 这一整套仓库从存储单元变成了协作单元。它的强项在对外开源项目天然在这里聚集贡献者不需要被邀请就能 fork、提 PR、参与讨论维护者的成本很低。企业版也提供了组织、团队、SAML 单点登录、审计日志这些能力但整体气质还是围绕人和协作设计的不是围绕流程门禁设计的。有个细节值得注意GitHub 的权限粒度是围绕仓库和团队角色来的Read、Triage、Write、Maintain、Admin配合 Rulesets 和 Branch Protection 能挡住直接推主干的动作但它默认假设分支上的提交是可信的评审是建议性、可绕过只要有权限的而不是强制的。这个假设决定了它适不适合做严肃的合规门禁。1.2 GitLab把整条交付链塞进一个产品GitLab 的思路是一个平台解决从计划到部署的全部环节。它把 Issue、看板、代码托管、Merge Request、CI/CD、制品库、容器镜像仓库、安全扫描、Pages、监控全部做进同一个应用里数据在同一个 PostgreSQL 里权限在同一套模型里页面在同一套导航里。这个设计带来的最大好处是少跳转。你提一个 MRPipeline 就在同一个页面跑Pipeline 里的镜像直接推到内置的 Registry部署完还能看到环境状态。对于不想把十几个工具拼起来的中小团队这个吸引力是致命的。GitLab 有社区版CE和企业版EECE 是开源许可功能覆盖了绝大多数团队的核心诉求代码托管、MR、CI/CD、Registry、Pages 全都有。EE 主要多了合规、审计、深度安全扫描、多级审批这些面向大企业的能力。自建的话官方提供 Omnibus 包deb/rpm、容器镜像、Helm Chart 三种主流方式社区版的安装包是公开下载的离线环境也能提前把包和依赖拉全再装。更关键的一点GitLab 的 CI/CD 是内建的不需要额外装 Jenkins 之类的东西去配 connection。它用.gitlab-ci.yml声明流水线GitLab Runner 执行支持 shell、docker、kubernetes 多种 executor。这套东西对我想让推代码自动跑测试然后自动部署的需求几乎是开箱即用的。1.3 Gerrit把评审做成一道物理门禁Gerrit 是另一个物种。它不是代码托管平台 评审功能而是评审是唯一的入库方式。在 Gerrit 的世界里你的本地 commit 不能直接推到分支上只能推到refs/for/branch这个虚拟引用推上去的每个 commit 会变成一个 Change必须拿到足够的评审票比如 Code-Review 2 加 Verified 1才能被 submit 合入。这个模型来自 Android 项目当年管理海量外部贡献者的现实需求几万个贡献者、每天上千个补丁、必须保证每一个进入主干的提交都被至少一个维护者看过、每一次修改都有完整历史。分支-PR 模型在这个规模下会失控因为分支会爆炸评审状态会散落。Gerrit 用 Change 这个更细的粒度解决了它。代价也很明显学习曲线陡。你得装commit-msghook 才能生成 Change-Id得学会推refs/for/得理解refs/changes/下的补丁集编号得接受一个 commit 一个 change的强制拆解。对于习惯git push origin main的人第一次用大概率会撞一头包。1.4 GerritHub不是平台是桥GerritHub 经常被误解成另一个 Git 平台实际上它是把 GitHub 和 Gerrit 拼起来的托管服务。你用 GitHub 账号登录把 GitHub 上的仓库导入进来然后走 Gerrit 的评审流程评审通过后再同步回 GitHub。它的价值场景很窄但很清晰代码想公开放在 GitHub 上获取社区曝光流程上又要 Gerrit 式的严格门禁。说白了它是给既要开源可见性、又要提交纪律的项目准备的折中方案不是一个从零开始搭代码平台的选项。个人或小团队自建环境时基本不需要考虑它。2. 机制差异才是重点Push 模型与 Change 模型2.1 GitHub/GitLab 的分支-PR 模型这两个平台共用一套心智模型分支是工作单元Pull Request / Merge Request 是评审载体合并动作由评审发起者或被授权者执行。具体流程是从主干切一个 feature 分支在分支上随便提交多少个 commit 都行推上去开 PR讨论改再推最后点合并按钮。合并策略可选 merge commit、squash、rebase历史形态由你控制。这套模型的好处是低摩擦。新人第一天就能上手因为它跟本地 Git 的直觉一致。分支天然隔离了工作评审是异步的、可回退的、可放弃的。坏处是历史容易烂。如果团队不约定 squash 或 rebase主干上会堆满fix typo再改一下真的最后一版这种提交。而且分支的生命周期一旦拉长合并冲突会变成灾难。解决这个问题的办法通常不是换平台而是加规则开启分支保护、要求线性历史、强制 squash 合并、加 CI 门禁。GitHub 用 Branch Protection Rulesets 做GitLab 用 Protected Branch Push Rules Merge Request Approval 做。2.2 Gerrit 的 Change 模型与那些绕不开的引用Gerrit 把工作单元从分支降到了单个 commit。一个 commit 就是一个 Change修改意见通过补丁集Patch Set迭代。你在本地用git commit --amend改同一个 commit再推一次Gerrit 会自动识别成同一个 Change 的新补丁集评审历史完整保留。这里的关键机制是 Change-Id。它写在 commit message 的最后一段格式类似修复批量导入时的空指针问题 Change-Id: I3f5a9c2b7e1d4f8a6c0b2e9d7f4a1c3e5b8d0f2a没有这个尾注Gerrit 会直接拒绝你的推送报错长这样! [remote rejected] HEAD - refs/for/master (missing Change-Id in commit message footer)生成它的方式是装 hook# 从 Gerrit 服务器拉取 hook curl -Lo .git/hooks/commit-msg http://gerrit.example.com/tools/hooks/commit-msg chmod x .git/hooks/commit-msg装完之后每次git commit都会自动往 message 尾部追加 Change-Id。这个 hook 必须对每个克隆都装一次是个典型的新人必踩的坑。推送目标也不是分支名而是特殊引用# 推送到评审队列 git push origin HEAD:refs/for/master # 带 topic 标记方便批量关联 git push origin HEAD:refs/for/master%topicbugfix-import # 已经是维护者想直接入库需要权限 git push origin HEAD:refs/heads/masterrefs/for/master是一个虚拟引用不真实存在于仓库里。Gerrit 拦截这个推送把 commit 转成 Change。对应的每个 Change 的每个补丁集在服务器上真实的引用长这样refs/changes/34/1234/2表示 1234 号 Change 的第 2 个补丁集。想拉某个特定补丁集下来看就 fetch 这个引用。2.3 提交粒度与历史整洁度的对照两种模型对提交质量的约束强度完全不同。分支-PR 模型里评审者看到的是分支上所有 commit 的集合只要最终合并后的结果对中间提交烂一点通常没人管。Gerrit 里每个 commit 都要单独拿票评审者必须逐个看所以它天然逼着开发者把提交拆干净、写清楚。这也是为什么很多用惯了 Gerrit 的人回不去 PR 模型以及为什么很多从 PR 模型迁到 Gerrit 的团队前期怨声载道——修改习惯要重建。下面这张表把核心机制差异摆在一起维度GitHubGitLabGerrit工作单元分支 PR分支 MR单个 commitChange推送目标refs/heads/*refs/heads/*refs/for/*评审强制力可配置有权限可绕过可配置审批规则可强制天然强制不拿票进不去改稿方式追加 commit 或 force push追加 commit 或 force push--amend生成新补丁集需要额外 hook否否是commit-msg线性历史保证靠分支保护规则靠分支保护规则天然线性Fast Forward Only3. 能力矩阵权限、CI、存储、生态逐项对比3.1 权限模型与分支保护的实际差异GitHub 的权限体系分两层组织层用团队Team聚合人仓库层给角色。角色从 Read 到 Admin 五档配合 Rulesets 可以做到某些路径只能特定团队改用 CODEOWNERS。审计日志在企业版里才完整。GitLab 的权限模型更细项目角色有五档Guest、Reporter、Developer、Maintainer、Owner群组可以继承Protected Branch 能精确到谁可以 merge、谁可以 push、谁都不能 push。EE 还支持多级审批规则比如必须产品 安全各批一次才能合。对流程要求严的组织这层能力比 GitHub 更顺手。Gerrit 的权限是围绕引用配置的。你可以给refs/heads/*、refs/for/*、refs/changes/*分别配不同权限甚至用 Prolog 写规则做动态判断比如只有改动了某个目录的文件才需要安全组投票。它还有 label 机制你可以自定义Code-Review、Verified、CI-Build之外的任意标签比如Security-Review并规定每个标签需要几张票、谁能投负票。这个粒度是另外两个平台做不到的。3.2 CI/CD内建、外挂与门禁的三种打法GitLab 的 CI 是亲儿子。.gitlab-ci.yml放在仓库根目录Runner 一注册推送即触发。一个典型的多阶段流水线是这样的stages: - test - build - deploy variables: IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA unit_test: stage: test image: python:3.11-slim script: - pip install -r requirements.txt - pytest --junitxmlreport.xml artifacts: reports: junit: report.xml paths: - report.xml expire_in: 7 days build_image: stage: build image: docker:24 services: - docker:24-dind script: - echo $CI_REGISTRY_PASSWORD | docker login -u $CI_REGISTRY_USER --password-stdin $CI_REGISTRY - docker build -t $IMAGE_TAG . - docker push $IMAGE_TAG only: - main deploy_prod: stage: deploy image: bitnami/kubectl:1.29 script: - mkdir -p ~/.kube - cp $KUBE_CONFIG ~/.kube/config - kubectl set image deployment/app app$IMAGE_TAG -n prod environment: name: prod when: manual only: - main几个容易踩的点$KUBE_CONFIG这类敏感变量要在项目设置里配成 File 类型不然换行会丢dind服务需要 Runner 开启 privilegedonly: main现在官方推荐改成rules:写法但only依然能用。生产部署那个 job 设成when: manual是个好习惯避免误触发。GitHub 这边用 Actions。它的优势是 Marketplace 上现成的 action 多到离谱几乎任何需求都能找到别人写好的步骤。劣势是 workflow 文件写起来啰嗦复杂流水线容易变成 YAML 迷宫而且私有仓库的分钟数是计费的。Gerrit 本身不带 CI它靠的是外部 CI 往 label 上投票。典型的做法是 Jenkins 监听 Gerrit 的 stream events收到patchset-created事件后拉取对应补丁集跑构建跑完通过 SSH 命令给Verified标签投 1 或 -1# Jenkins 侧给补丁集投票 ssh -p 29418 jenkinsgerrit.example.com \ gerrit review --verified 1 --message 构建通过 \ 1234,2注意那个1234,2是 Change 号和补丁集号。这个设计的好处是 CI 和评审彻底解耦换 CI 系统不影响 Gerrit坏处是链路长出问题要两头查。3.3 检索、存储与周边生态GitHub 的代码搜索和跨仓库检索能力是三个里最强的公开代码的检索价值几乎是不可替代的。GitLab 有全局搜索和高级搜索EE 更强自建环境的 Elasticsearch 集成需要额外配。Gerrit 的搜索是围绕 Change 设计的你想按 owner:self status:open label:Code-Review2 这种条件筛 change 很方便但做全文代码搜索不是它的强项。存储层面GitHub 是托管服务你不需要关心GitLab 自建要关注磁盘仓库 制品 镜像 日志一起涨很容易把盘吃满Gerrit 自建主要是仓库 索引压力小很多但它对 NoteDb 的备份要求更严配置不当恢复会很痛苦。周边生态一句话概括GitHub 最广GitLab 最全Gerrit 最窄但最深。选之前先想清楚自己是需要什么都能接上还是需要某一件事做到极致。4. 选型决策按规模和流程成熟度对号入座4.1 什么情况下闭着眼睛选 GitHub三种情况基本可以不用犹豫。第一种项目要开源、要吸引外部贡献者。生态效应摆在那贡献者不会为了给你提个 PR 专门去注册别的平台。第二种团队小、流程轻主要诉求是代码有地方放、能评审、能跑个自动测试。Actions 加 Branch Protection 就够了自己维护服务器的时间省下来干正事。第三种需要重度依赖第三方集成比如各种 SaaS 的部署钩子、项目管理工具、安全扫描服务它们对 GitHub 的支持通常最全。要接受的前提是托管意味着你的代码在别人的机器上合规要求高的场景要提前评估另外免费额度、私有仓库限制、Actions 分钟数这些账要算清楚团队规模上去之后成本不是小数。4.2 什么时候必须自建 GitLab出现下面任意一条自建 GitLab 就该进入候选代码不能出内网、有明确的数据驻留要求、需要 GitLab CI 那种提交即流水线的一体化体验、希望把制品库和容器镜像仓库跟代码放一起管、团队人不多但想要一套完整的 DevOps 工具链而不是拼装一堆。自建 GitLab 最需要注意的是资源和运维成本。官方推荐的最低配置在实际使用中基本不够用真正跑起来给 20 人团队用4 核 8G 只是起点磁盘要按仓库大小 × 3 到 5 倍预留因为制品、镜像、备份、日志都会占地方。备份策略必须提前设计不能等出事再想。4.3 什么时候该上 Gerrit判断标准很单一你的项目是否到了每一次进入主干的改动都必须被人工审视、且不能有任何绕过路径的程度。典型信号包括参与贡献的人成百上千且大部分是外部人员、代码质量事故的代价极高比如涉及底层系统或硬件固件、审计要求每个改动都要留下完整评审记录、主干必须保持严格线性且随时可发布。如果只是我们想规范一点别上 Gerrit。它的学习成本和流程刚性对小团队是净负担。如果确实需要那它带来的历史整洁度和评审可追溯性是 PR 模型很难比的。4.4 一张决策表直接对号你的处境首选理由开源项目要外部贡献GitHub生态和曝光不可替代3-15 人小队快速迭代GitLab CE 自建 或 GitHub一体化程度高运维成本可接受代码不能出内网GitLab CE 自建 或 Gerrit完全可控需要严格审计与强制门禁Gerrit评审即门禁无绕过路径大厂底层项目外部贡献多Gerrit 主 GitHub 镜像展示门禁与曝光兼顾想要 CI/CD 开箱即用GitLab.gitlab-ci.yml内建支持已有 Jenkins只想换代码平台Gerrit 或 GitLab两者都能跟 Jenkins 对接就想要个免费私有仓库GitLab CE 自建无分钟数限制5. 落地实操从零搭起的关键步骤与配置5.1 GitLab 社区版容器化部署的实操要点用容器方式搭 GitLab CE 是最省事的路径但有几个参数不写对后面会一直出问题。docker run -d \ --name gitlab \ --hostname gitlab.example.com \ --restart always \ -p 8443:443 -p 8081:80 -p 2222:22 \ -v /srv/gitlab/config:/etc/gitlab \ -v /srv/gitlab/logs:/var/log/gitlab \ -v /srv/gitlab/data:/var/opt/gitlab \ -e GITLAB_OMNIBUS_CONFIGexternal_url https://gitlab.example.com; gitlab_rails[gitlab_shell_ssh_port]2222; nginx[listen_port]80; letsencrypt[enable]false \ gitlab/gitlab-ce:latest拆开说每个点为什么这么写。端口映射把宿主机的 8081 对到容器 80是为了避开宿主机上可能已经在跑的 80 端口服务这个冲突非常常见。SSH 映射到 2222 是因为宿主机 22 通常被系统 sshd 占了如果 SSH 端口映射了但gitlab_shell_ssh_port没同步改成 2222克隆时给出的地址会指向 22直接连不上。external_url必须跟实际访问地址完全一致否则页面里的链接、clone 地址、webhook 回调全是错的。三个数据卷一个都不能省。/etc/gitlab装配置和密钥/var/log/gitlab是日志/var/opt/gitlab是仓库数据。备份的时候gitlab-backup create只备数据部分配置文件不在里面恢复时必须保证配置文件跟备份是同一版本的状态否则会失败。这是我见过最容易翻车的地方。启动后等初始化完成大概 2 到 5 分钟取决于机器拿初始密码docker exec -it gitlab grep Password: /etc/gitlab/initial_root_password登录后第一件事改密码第二件事去设置 - 通用里把外部访问的域名和 SSH 端口确认一遍。5.2 SSH 密钥与代码拉取的完整链路不管用哪个平台SSH 密钥配不对后面所有操作都难受。生成一对ssh-keygen -t ed25519 -C your_emailexample.com -f ~/.ssh/id_ed25519_gitlab用 ed25519 而不是 RSA 是因为它更短更快现在的平台都支持。多平台共存时靠~/.ssh/config分流Host gitlab.example.com HostName gitlab.example.com Port 2222 User git IdentityFile ~/.ssh/id_ed25519_gitlab IdentitiesOnly yes Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github IdentitiesOnly yesIdentitiesOnly yes这行很关键不加的话 SSH 会把所有密钥挨个试一遍某些服务器在试错次数超限后直接断开表现为密钥明明加了但认证失败。验证连通性ssh -T gitgitlab.example.com # 返回 Welcome to GitLab, username! 就是通了拉取代码时有个常见困惑页面给的 clone 地址如果带着机器 ID 或者一长串随机域名说明external_url没配好。正确做法是在gitlab.rb里把external_url改成你的真实域名然后执行docker exec -it gitlab gitlab-ctl reconfigure改external_url之后必须 reconfigure光改文件不生效。这个动作会重新生成 nginx 配置和一堆内部链接耗时几分钟是正常的。5.3 Gerrit 的初始化与评审流程打通Gerrit 初始化比 GitLab 轻但配置项更绕。装完之后第一步是建第一个管理员账号然后创建项目ssh -p 29418 admingerrit.example.com gerrit create-project \ --parent All-Projects \ --owner Administrators \ --description 核心服务 \ core-service接着给项目配权限。最需要改的是refs/heads/*的 Submit 权限默认只有管理员能直接推正常流程应该只允许通过refs/for/*提交然后由 label 门禁放行。同时把强制 Change-Id 的选项打开这样没装 hook 的提交会在推送时就被拒绝错误暴露得早比在评审阶段才发现强。如果项目里已经有代码把现有仓库导入# 从现有仓库克隆裸版本 git clone --bare https://github.com/example/legacy.git legacy.git cd legacy.git # 推到 Gerrit git push ssh://admingerrit.example.com:29418/core-service refs/heads/*:refs/heads/*这里要提一句Gerrit 默认策略下直接推refs/heads/*需要对应权限批量导入时用管理员账号操作导入完成后再收紧权限。导入完别忘了在项目配置里设置 Submit Type想要严格线性历史就选 Fast Forward Only。Jenkins 侧的对接核心是两件事装 Gerrit Trigger 插件并配置 Gerrit 服务器连接和事件监听在构建后步骤里用gerrit review命令投票。这里有个坑投票用的 SSH 密钥和 Jenkins 用的密钥不是一回事需要单独在 Gerrit 上给 jenkins 账号配 SSH 公钥并且这个账号要有Label Verified的投票权限否则构建跑成功但投不进去票Change 永远卡在那里。5.4 迁移与共存别想一次全搬完现实中很少是从零选一个更多是已经在用 A想加 B或者想从 A 换到 B。我的建议是共存期一定要留。从 GitHub 迁到自建 GitLab代码本身好迁git clone --mirror再push --mirror就完了。难迁的是 Issue、PR 讨论、Wiki。GitLab 官方提供了导入工具但评论和状态映射经常不完整。实际做法是代码先迁旧仓库设为只读并保留一段时间做查询新工作全部在新平台开不要试图把历史对话搬过来。从 GitHub 迁到 Gerrit 更要注意Gerrit 不接受一个分支上有一堆杂乱提交导入后如果主干历史不线性设置 Fast Forward Only 会导致后续提交推不上去。这种情况下要么接受 Merge If Necessary要么重新整理历史——后者对活跃项目基本不现实。镜像保留的问题如果内网 GitLab 是主力同时想在 GitHub 上展示代码可以用推送镜像的方式做单向同步。要注意方向必须是单向双向同步的冲突解决成本很高容易把两边都搞乱。6. 常见坑与排查清单6.1 认证与权限类问题速查这类问题占了实际求助的一大半基本都是配置问题。现象真实原因处理方式SSH 提示 Permission denied公钥没加、密钥选错、config 缺 IdentitiesOnly用ssh -vT看用了哪把密钥能 clone 不能 push角色是 Reporter 或分支受保护在项目成员页确认角色页面 clone 地址是机器 IDexternal_url没配或没 reconfigure改配置后执行 reconfigure登录报 token 或版本错误API token 过期或客户端版本与服务器不匹配重新生成 token检查客户端版本Gerrit 提示 not permitted: create没有目标分支的推送权限用refs/for/而非refs/heads/切换账号后仍用旧身份凭据管理器缓存了旧凭证清掉系统凭据里的对应条目关于 GitLab 账号自建实例默认关闭注册需要管理员在后台创建用户或者临时开放注册再关闭。很多人第一次自建完发现注册不了就是没意识到这一点。6.2 提交被拒的典型报错与原因Gerrit 的报错信息其实很直白看懂关键词就好办。# 缺 Change-Id ! [remote rejected] HEAD - refs/for/master (missing Change-Id in commit message footer) # 解决安装 commit-msg hook 后 git commit --amend 重新生成 # 没有新改动 ! [remote rejected] HEAD - refs/for/master (no new changes) # 原因你推的 commit 内容跟已有补丁集完全一样把改动 amend 进同一个 commit 再推 # 直接推主干被拒 ! [remote rejected] HEAD - refs/heads/master (prohibited by Gerrit) # 原因没有直接推送权限改推 refs/for/masterno new changes这个报错特别常见于改了代码但忘了git add或者改了文件但内容跟上一版一样。推到评审队列之前先git status看一眼能省不少来回。GitLab 那边常见的推送失败是分支受保护和pre-receive hook 拒绝。前者去项目设置里看 Protected Branches 列表确认你的角色在 Allowed to push 里后者通常是 Push Rules 配了提交信息必须符合正则之类的规则去设置里核对规则内容。6.3 CI 不触发与流水线卡住的排查GitLab 的流水线卡在 pending 状态九成是 Runner 的问题。检查顺序是Runner 是否在线设置 - CI/CD - Runner 里看绿点、Runner 的 tag 跟 job 的 tag 是否匹配、Runner 是否设置了只运行带 tag 的 job而你的 job 没打 tag。这三种情况在页面上都不报错只显示等待特别容易让人怀疑人生。# 在 Runner 机器上查看注册状态和并发配置 gitlab-runner list gitlab-runner verify另一个高频问题是容器化构建里用 docker 命令失败报Cannot connect to the Docker daemon。原因是 Runner 用了 docker executor 但没挂载宿主机的 docker socket或者用了 dind 服务但没开 privileged。两种方案选一个挂 socket 简单但隔离性差dind 隔离好但配置多几行。另外DOCKER_HOST环境变量没设也会导致构建脚本里的 docker 命令找不到 daemon。Gerrit 这边 CI 不通先看 Jenkins 的 Gerrit Trigger 有没有收到事件。没收到就去 Gerrit 侧检查 stream events 的连接和监听配置收到但没触发构建看项目名和分支的匹配规则。这类问题的排查最好打开 Jenkins 的系统日志实时看比翻历史记录快得多。6.4 备份、恢复与版本升级的注意事项GitLab 的备份有个硬约束备份文件必须和恢复时的 GitLab 版本一致至少是相同主版本。跨版本恢复基本会失败正确姿势是先恢复到同版本再逐步升级。# 备份在容器内执行 docker exec -t gitlab gitlab-backup create # 备份文件默认在 /var/opt/gitlab/backups 下 # 恢复前先把配置文件也备份一份 docker exec -t gitlab tar -czf /tmp/etc-backup.tar.gz /etc/gitlab恢复的时候/etc/gitlab/gitlab-secrets.json必须跟备份时一致否则所有加密数据都读不出来包括 CI 变量、Registry 凭据。这个文件丢了数据基本等于废了。所以完整的备份方案是数据备份 配置文件 secrets 文件三件套缺一不可。磁盘空间也要盯。GitLab 跑久了/var/log/gitlab能吃掉几十个 GRegistry 和制品库也会无限膨胀。建议配一个定期清理策略日志用 logrotate制品设过期时间备份文件保留最近若干份镜像定期清理未打 tag 的层。Gerrit 的备份相对简单主要是仓库目录加etc目录。新版用 NoteDb元数据都在 Git 仓库里备份仓库目录基本就够。但升级前一定要读对应版本的 release notes因为索引格式变化时升级后需要重建索引这个步骤漏掉会导致搜索功能异常。最后分享一个我踩过的坑自建平台上做测试环境时很多人习惯直接复制生产配置结果两个实例用了相同的 secrets 文件后来做单点登录和跨实例跳转的时候出现诡异的身份串号问题。自建服务在复制配置时一定要重新生成密钥和 secrets或者明确知道哪些能复用、哪些必须区分。这个教训不便宜。