Git仓库迁移至新URI时如何处理历史版本中的submodule问题

该方案完全具备可行性，且可以通过Git原生能力优化掉「发布检出结果处于dirty状态」的缺陷。
你之前担心dirty状态的核心原因是直接修改了工作区的.gitmodules文件或子模块的本地远程地址，实际上Git原生支持拉取时自动替换匹配的URL前缀，无需修改任何已提交的代码文件，也不会变更工作区内容。

以下方案按落地成本从低到高、收益从短期到长期排序：

• 首选Git原生URL重写规则
  在构建环境或元构建仓库的初始化脚本中执行以下命令即可全局适配所有旧URI：

  # 将所有旧BitBucket前缀的URI自动替换为新GitLab前缀
  git config --global url."https://你的本地GitLab域名/".insteadOf "https://旧BitBucket域名/"
  # 可添加多条规则覆盖所有历史使用过的旧托管地址
  git config --global url."https://你的本地GitLab域名/".insteadOf "https://github.com/"
  

  该规则仅作用于Git拉取逻辑，不会修改任何已提交的文件或工作区内容，完全不会出现仓库dirty的问题，无需修改任何旧版本代码即可完成适配。
• 内部统一使用固定Git域名别名
  为避免后续更换托管服务再次出现同类问题，可在内部DNS中配置一个永久不变的Git服务域名（例如git.internal.your-company.com），始终指向当前使用的托管服务地址。后续所有仓库的submodule URI统一使用该别名，更换托管时仅需修改DNS解析规则，无需调整任何代码或配置。
• 依赖配置统一收敛到元构建仓库
  如果计划替换Git Submodule做依赖管理，不管选用CMake ExternalProject()、Conan还是vcpkg，都将所有依赖的URI、版本校验规则全部存放在元构建仓库中，业务代码仓库不保留任何依赖地址配置。后续迁移仅需要修改元仓库的统一配置，所有旧版本构建会自动适配新地址。

关于重写Git历史的风险说明 #

重写全量历史修改submodule URI会变更所有关联提交的哈希值，导致已有本地克隆、历史发布标签、问题单/文档中关联的提交哈希全部失效，团队所有成员需要重新克隆仓库，历史溯源成本极高，除非存量旧URI存在安全风险否则完全不推荐使用。

内容的提问来源于stack exchange，提问作者radix