GitLab 私有化部署太吃内存：只留仓库和合并请求

这篇讲内网 GitLab 占着大内存、团队却只用仓库和评审时，怎么把这三件事放到更轻的 AngusGit 上。看完你可以按团队建好仓库并连同历史迁入，配好合并方式和分支保护，构建继续留在 Jenkins，制品继续留在制品仓库。

先登录 AngusGit。搬一个仓库时，在 设置 → 团队 点 新建团队，团队标识 沿用 GitLab 组的英文名。侧栏 仓库 → 新建仓库，所有者选这个团队，添加 README 文件、添加 .gitignore、选择许可证 都不要勾，否则推送会因为历史对不上被拒绝。本机没有公钥时执行 ssh-keygen -t ed25519 -C "you@example.com"，把 cat ~/.ssh/id_ed25519.pub 的那一行登记到 我的 → SSH密钥。然后执行（地址换成你的；主分支叫 master 时先在裸仓库里 git branch -m master main）：

git clone --bare https://gitlab.example.com/组/项目.git
cd 项目.git
git push ssh://git@git.example.com:2222/团队/仓库.git --all
git push ssh://git@git.example.com:2222/团队/仓库.git --tags

用户名是 git，端口是 2222。改用 HTTPS 时，到 我的 → 访问令牌 生成一把勾了 git:write、仓库权限为 WRITE 的令牌，用户名填登录名，密码填令牌。验收用下面的命令，没有意外输出就是两边一致：

diff \
  <(git ls-remote --heads --tags https://gitlab.example.com/组/项目.git | sort) \
  <(git ls-remote --heads --tags ssh://git@git.example.com:2222/团队/仓库.git | sort)

仓库多时，把 GitLab 路径和「团队/仓库名」每行一对写进 repos.txt，对每一行重复上面的克隆和推送。先手动成功推一个，并在系统凭据窗口里保存令牌，再跑循环。master 改成 main 时，这一对名字不同是预期的。

拉取请求在 GitLab 里叫合并请求（Merge Request），和 AngusGit 页面上的拉取请求是同一件事。

GitLab 占内存，是因为它的一体化安装包里带了数据库、缓存、后台任务、内置 CI、容器镜像仓库和监控等一整套组件，即使只用代码托管，这些进程也一直在后台运行。如果你们的流水线已经在 Jenkins 上跑、制品也有单独的仓库，那么用 2 核 4 GB 起步的 AngusGit 承接仓库、拉取请求和代码评审这三件事就够了。

1. 先确认：团队真的只用这三件事吗

动手之前，先花十分钟确认现有 GitLab 上哪些功能真的在用。可以对照下表逐项问一遍：

Git LFS 是把大文件存在仓库之外的 Git 扩展。如果 GitLab CI 和 Git LFS 这两行的答案都是「不用」，拆分会很顺利；如果团队重度依赖 GitLab CI，先看文末参考里的选型一文，评估流水线怎么处理。

2. 第一件：仓库

AngusGit 上的仓库都挂在团队下面，地址形如 ssh://git@git.example.com:2222/团队/仓库.git。所以搬仓库分三步：先建团队，再把仓库搬过来，最后让开发者改远程地址。

1. 按现在的分组建团队

   在 设置 → 团队 里 新建团队，一个团队对应 GitLab 上的一个组。团队标识 会出现在仓库地址里，建议沿用 GitLab 组的英文名，这样大家改远程地址时更好记。

2. 把仓库连同历史搬过来

   先在 AngusGit 上新建同名的空仓库，然后用 git clone --bare 从 GitLab 克隆一份完整副本（裸仓库只存 Git 数据，没有可编辑的工作区），再用 git push --all 和 git push --tags 推到 AngusGit。这样提交历史、全部分支和标签都会带过来。

3. 让开发者改远程地址

   每个人在本地仓库里执行 git remote set-url origin，把远程地址换成新地址。用 SSH 的，先在 我的 → SSH密钥 登记公钥；用 HTTPS 的，密码一栏填 我的 → 访问令牌 里生成的令牌。

命令、凭据和两边对比见开头。先手动成功推一个仓库，再对 repos.txt 里的每一行重复同样的克隆和推送。

3. 第二件：合并请求

在 AngusGit 上，合并请求叫 拉取请求，用法和 GitLab 的 Merge Request 一样：从功能分支发起，合进 main。

需要提前定下来的是合并方式。打开仓库的 设置 → 拉取请求，这里有三个开关：合并提交、压缩合并、变基合并。只打开团队约定的那一种，合并框里就只会出现这一种，避免每个人按自己的习惯选。如果还没想好选哪种：想保留每个提交，选合并提交；希望一个拉取请求在 main 上只留下一条提交，选压缩合并。三种方式的详细区别见文末参考里的合并方式一文。

4. 第三件：人工评审

评审在侧栏的 评审 里完成。评审人打开 待评审 里的一条拉取请求，在 文件变更 里逐个文件看差异，在需要讨论的行上留言，最后点 提交评审，选择 批准、请求更改 或 评论。

以还开着的 xlliu/test-cicd-example #1 为例，它的标题是「SC-02/SC-04 PR trigger verification」，状态是 待评审。页面左侧是文件树，两个文件都还没有标记为已查看；右侧展开的是 apps/service-a/src/index.js，新增了两行，目前还没有行评。点右上角的 提交评审 会弹出一个对话框，标题同样是「提交评审」，说明文字是「选择你的评审决定并添加评论」，下面有 批准、请求更改、评论 三个选项。选好结论、再点对话框里的 提交评审，评审才算提交；只打开对话框，状态仍然是 待评审。

到这一步，评审人批不批准还只能靠自觉。要把评审变成必须遵守的规定，需要打开分支保护，也就是给分支加上「禁止直接推送、合并前必须满足条件」的规则：

1. 保护主分支

   打开仓库的 设置 → 分支保护，给 main 添加一条规则：打开 需要代码评审，必需的评审人数 填 1，并打开 对管理员同样生效。保存之后，直接推送 main 会被拒绝，改动必须通过拉取请求、拿到批准后才能合并。

2. 按目录指定评审人（可选）

   如果不同目录由不同的人负责，就在仓库里加一个 CODEOWNERS 文件，写明每个目录的负责人。之后创建拉取请求时，系统会自动把对应的人加为评审人。

配好之后，团队每天的流程就固定为：开分支、推送、发起拉取请求、评审人批准、合并。每一项的具体设置见文末参考里的分支保护和 CODEOWNERS 两篇。

5. 不放进来的功能，交给谁

仓库、拉取请求和评审之外的功能，继续交给各自的专职系统，对应关系如下：

构建这一行要注意触发方式。Webhook 是代码有变动时自动通知外部系统的机制，而 AngusGit 的推送 Webhook 只在 git push 时发出，所以在网页上合并拉取请求之后，建议让 Jenkins 配合 Poll SCM（轮询 SCM，定时检查分支有没有新提交）来发现新代码。

这样拆分之后，每个系统各管一件事，出了问题也更容易定位是哪一边。

常见问题

拆出来之后，原来的 GitLab 怎么办？

先不要删。把 GitLab 改为只读，保留一段时间，方便回查旧的合并请求和讨论记录；确认没有遗漏后再归档。迁移期间怎么双跑（新旧平台并行一段时间，期间只让一边可写）、出了问题怎么回滚，见文末参考里的迁移清单一文。

以后又需要内置流水线了怎么办？

AngusGit 的团队版和企业版带内置流水线，换用对应的安装包即可，已有的仓库和拉取请求数据不受影响。

社区版人数不够怎么办？

社区版最多 10 个用户，超过时换用团队版或企业版，仓库、拉取请求和评审的用法都不变。

小结

GitLab 私有化部署吃内存，很多时候是因为一整套组件都在运行，而团队只用其中三件事。把仓库、拉取请求和人工评审搬到 AngusGit 上：仓库按团队建好，连同历史一起搬过来；合并方式在 设置 → 拉取请求 里统一；评审在 评审 里完成，再用分支保护和 CODEOWNERS 把它变成规定。构建继续交给 Jenkins，镜像和软件包放到制品仓库；以后需要内置流水线时，换用团队版或企业版即可。

结论： 只保留仓库、拉取请求和代码评审三件事时，用 2 核 4 GB 起步的 AngusGit 加 GM 就能替代重型 GitLab，构建和制品分别留给 Jenkins 和制品仓库。