重命名Git仓库除修改远端地址外还有哪些副作用？

除了开发人员需要在本地执行git remote set-url origin new_url修改远端地址外，公司私有部署场景下还可能存在以下实际副作用：

• 内部系统链路失效
  所有硬编码了旧仓库地址的系统都会出现故障，常见包括CI/CD流水线（Jenkins、GitLab CI等）的拉取代码步骤、内网Wiki/文档里的仓库跳转链接、私有依赖库（Go Module、npm私有源、Maven私有库等）的依赖引用配置，重命名后需要逐一排查修改这些关联配置。
• 仓库绑定规则失效
  部分旧版本私有Git服务（自建GitLab、Gitea、Bitbucket Server等）如果此前是通过仓库完整路径配置的细粒度权限、WebHook、部署密钥、CI环境变量，重命名后路径变更可能导致上述规则关联失效，需要重新核对配置是否正常。
• 派生仓库关联断裂
  如果该仓库存在内部人员Fork的副本，重命名原仓库后，所有Fork副本默认绑定的上游地址依然是旧地址，Fork用户同步上游代码、向原仓库提交PR的操作都会直接失败，大部分私有Git服务不会自动更新Fork副本的上游配置，需要单独通知相关用户修改。
• 本地自定义脚本故障
  团队内部如果存在硬编码了旧仓库名称/路径的本地自动化脚本（比如批量拉取仓库脚本、自动部署脚本），相关脚本运行时会直接报错，需要通知所有开发自行核对修改本地脚本配置。
• 未更新remote的用户操作失败
  部分老旧私有Git服务不支持旧地址自动301重定向，或是开发人员使用的Git版本过旧无法识别重定向规则，在修改remote地址前，所有拉取、推送操作都会直接报错，无明确提示的情况下容易让用户误以为仓库服务故障。

可在重命名前梳理全公司范围内的旧地址引用提前修改，重命名后保留旧地址跳转规则1-2个月，即可规避绝大多数问题。

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