我如何使用 Bash 自动化完整的 GitLab 迁移（真实案例研究 + 脚本）
发布: (2025年12月2日 GMT+8 09:59)
4 min read
原文: Dev.to
Source: Dev.to
在 GitLab 实例之间迁移多个仓库很容易变得复杂且重复——尤其是当涉及 组、子组、CI/CD 流水线、变量、标签和议题 时。
为高效解决此挑战，我编写了一套 Bash 自动化脚本，用于将项目从 自托管的 GitLab Community Edition 迁移到 GitLab Enterprise（gitlab.com）。本文概述了方法、结构和收益，完整工具包现已开源供社区使用。
为什么要自动化迁移？
在迁移大规模环境时，手动工作会出现：
- ❌ 耗时
- ❌ 易出错
- ❌ 难以追踪或复现
自动化可以确保过程：
- ✔️ 可重复
- ✔️ 可审计
- ✔️ 安全
- ✔️ 可扩展
- ✔️ 更快
工具包包含哪些内容？
| 脚本 | 用途 |
|---|---|
clone-projects.sh | 从源 GitLab 组克隆所有仓库 |
replace_gitlab-ci.sh | 为新路径更新 .gitlab-ci.yml 引用 |
push-projects.sh | 将分支和标签推送到目标 GitLab 实例 |
migrar-variaveis.sh | 通过 API 迁移组级环境变量 |
migrar_issues.sh | 迁移议题和评论并保留元数据 |
delete-issues.sh | 在重置暂存/测试环境时删除议题 |
gitlab-clone-recursive.sh | 递归克隆嵌套的组和子组 |
gitlab-push-recursive.sh | 推送仓库并自动重新创建缺失的子组 |
每个脚本都包含：
- 验证逻辑
- 日志记录
- 备份行为
- 幂等执行（安全可重复运行）
工作原理（高层工作流）
- 从源 GitLab 克隆仓库。
- 如有需要，应用 CI/CD 路径替换。
- 将仓库（分支 + 标签）推送到目标实例。
- 迁移变量、议题和元数据。
- 验证并完成迁移。
此流程支持 增量迁移，适用于大规模环境。
完整源代码
完整源代码已在公共仓库中提供（为简洁起见省略链接）。
最终结果
通过此自动化，我们实现了：
- ✅ 所有仓库完整迁移
- ✅ 保留历史、分支和标签
- ✅ 以最少人工操作复用 CI/CD 流水线
- ✅ 可控且可重复的过程
最后说明
本项目是在一次真实的 GitLab 迁移中发现缺乏清晰、完整且自动化的指南后创建的——尤其是缺少对仓库、CI/CD 文件、变量、分支、标签和议题的结构化安全处理。
第一版使用 Bash 编写，因为作者在 Linux 自动化和 Shell 脚本方面有深厚背景，能够快速开发并实现可靠迁移。长期目标是将解决方案重构为 Python，使其更灵活、易维护且模块化，以便未来改进。
如果你有兴趣贡献代码、改进功能或帮助进行 Python 重写，欢迎加入——我们期待合作。
如果此项目为你节省了时间、提供了更好的思路或哪怕帮助了一点，发布它就是值得的。让我们一起让 DevOps 社区更强大。 🚀
如果你正在计划或执行 GitLab 迁移，欢迎 fork、适配并贡献改进。
欢迎反馈与合作！