迁移

一场本不该发生的迁移 我认识一个团队，花了三周时间把 120 个 Go 服务从一个 Git 平台迁移到另一个。代码搬迁只用了一天。剩下的两周半？在更新每一个 repo、每一条 CI 流水线、每一个 Dockerfile、每一个下游消费者的 import path。 最扎心的是：他们之前已经经历过一次了。两年前从 SVN 迁移到 Git，那时候也重写了所有 import path。 这种悲剧反复上演，因为大多数团队把 import path 当作偶然的——Git 平台给什么路径就用什么。但 import path 是身份标识。它是所有下游项目找到你的代码的方式。改了身份，就断了所有依赖你的人。 这篇文章讲的是如何让 import path 稳定——代码可以搬，基础设施可以换，import path 永远不用改。 Import Path 为什么会断 先盘点一下哪些情况会迫使你修改 import path： 触发事件 发生什么 影响范围 Git 平台迁移 GitHub → GitLab，或迁到自建平台 所有模块，所有消费者 组织重命名 公司改名，GitHub org 名称变更 所有模块，所有消费者 仓库转移 把 repo 移到另一个 org 该模块 + 所有消费者 拆分 Monorepo 大仓拆成独立仓库 拆出的模块 + 消费者 合并为 Monorepo 多个独立仓库合入大仓 每个合入的模块 + 消费者 服务器搬迁 自建 Git 服务器 IP/域名变更 所有模块，所有消费者 发现规律了吗？每一个都是基础设施变更，不是代码变更。 你的代码没变，API 没变，但所有下游项目都要更新 go.mod、跑 go mod tidy、做一次完整的回归测试——只因为地址变了。 ...