从 GitHub / GitLab 迁移：搬代码只是第一步
迁移最容易被低估的地方：代码搬过来十分钟，周边配置对不上要一星期。
这篇按「先搬什么 → 怎么搬 → 搬完改什么」走。
一、先决定搬多重
三种粒度，成本差一个数量级：
| 粒度 | 做法 | 适合 |
|---|---|---|
| 只搬代码 | git push --mirror | 试水、个人项目 |
| 代码 + 制品 | 加制品迁移工具 | 有内部包依赖 |
| 代码 + 制品 + 协同数据 | 加项目协同迁移工具 | 团队整体搬迁 |
别一上来就全量搬。先搬一个仓库跑通流水线，再批量。
二、只搬代码：--mirror 最快
保留全部分支和标签的历史：
# 1. 克隆裸仓库
git clone --bare https://github.com/example/example-repo.git
# 2. 推送到 CNB，--mirror 同步所有分支与标签
cd example-repo.git
git push --mirror https://cnb.cool/my-group/example-repo.git
# 3. 清理
cd .. && rm -rf example-repo.git
只想搬某个分支，普通 clone 后逐个 git push 即可，不必上 --mirror。
:::tip 一个必须提前确认的点
CNB 默认分支通常是 main，从其他平台迁移的仓库可能是 master。
搬之前想好要不要统一——因为 .cnb.yml 的顶层键名就是分支名，写错了流水线一条都不跑。
:::
三、批量搬：Code Import
仓库一多，手敲 --mirror 不现实。官方工具是 CNB Code Import，支持从 GitHub、GitLab、Gitee 等平台批量导入。
工具地址：cnb/plugins/cnbcool/code-import
典型的批量场景是几十上百个仓库一次性搬，这时候要看的是：导入失败的仓库有没有清单、中断了能不能续。
四、不搬，而是保持同步：Git Sync
有些团队没法一刀切。老平台还要用一阵，新平台先并行。
Git Sync 是跨平台同步插件，把一边的变更自动同步到另一边。工具地址：cnb/plugins/tencentcom/git-sync。
用它的前提是想清楚谁是主：单向同步（老 → 新）安全，双向同步冲突处理会很痛苦。
五、制品也要搬
从其他制品仓库迁 Maven、npm、Composer、NuGet 类型制品到 CNB，用 artifact-migrate：
cnb/plugins/cnbcool/artifact-migrate这一步经常被跳过，然后在新平台上第一次构建就挂——因为依赖拉不到。
六、协同数据
CODING 的项目协同数据可以迁到 TAPD 或 CNB，工具：CODING/tool/migrate-collaboration。
GitHub 的 Issue / PR 没有官方一键工具，通常的做法是导出 JSON 再脚本化写进 CNB 的 Issue（CLI 能批量建）。
七、搬完必改清单
这部分是真正的成本所在。逐条对：
| 要改的东西 | 为什么 |
|---|---|
本地 git remote 地址 | 老地址推不上去 |
.cnb.yml 里的硬编码仓库路径 | 组织名变了就失效 |
| CI 里引用的镜像地址 | 私有镜像仓库换了 |
imports 引用的密钥仓库路径 | 密钥没搬 = 构建起不来 |
| 分支保护规则 | 不在 git 里，得重新配，容易忘 |
| 组织成员与角色 | 权限模型不一样，别照搬 |
| Webhook / 外部集成回调地址 | 指向旧平台的要改 |
| 徽章链接 | README 里的图片会 404 |
:::tip 先配密钥仓库
迁移后第一次构建失败，八成是环境变量没了。把密钥仓库建好、imports 改对，再跑第一次构建。
:::
八、迁移后的验收标准
别用「能克隆」当成功。真正的标准是：
- 默认分支的
push流水线能跑通 - 能开 PR 且 PR 流水线能跑
- 制品能拉能推
- 分支保护生效（试着直推主干，应该被拒）
四条全过，才算搬完。
下一篇是这套教程的收尾：把所有高频问题串成一张排查地图。