远端 Git 仓库 URL 变更导致 ECS 热更新链路中断，需定位受影响节点、批量更新远程地址、校准认证方式并闭环验证。一、检查部署脚本、配置中心及本地 remote；二、用运维工具批量执行 git remote set-url；三、适配 HTTPS+PAT 或 SSH 认证；四、手动触发更新、验证 commit、启用多远程备份。
远端 Git 仓库 URL 变更导致弹性云服务器（ECS）热更新链路瘫痪，本质是自动化流程中“拉取源”失效，而非代码本身损坏。关键不是重装或全量覆盖，而是快速恢复本地 Git 配置与远程通信能力，并保障多节点批量同步的一致性。
一、定位受影响的 ECS 节点范围
先确认哪些服务器在热更新时依赖该 Git 地址：
- 检查部署脚本中硬编码的 git clone 或 git pull 命令（常见于 /opt/deploy/update.sh、systemd service 文件或 CI/CD runner 的 job 模板）
- 排查是否使用了统一配置中心（如 Consul、Nacos）下发仓库地址，若存在，优先更新配置中心项
- 对已上线节点，执行 git remote -v（进入项目目录后）验证当前 origin 是否仍指向旧 URL
二、批量修复本地 Git 远程地址
避免逐台 SSH 登录修改，推荐以下高效方式：
- 通过运维平台（如阿里云 SMC、Ansible、SaltStack）下发命令：
git -C /path/to/project remote set-url origin https://new-domain.com/user/repo.git - 若使用 SSH 协议且私钥未变更，仅需替换域名和路径，例如：
git -C /path/to/project remote set-url origin git@new-git-server.com:user/repo.git - 对无自动化工具的场景，可编写简易 Bash 脚本配合 sshpass 批量执行（注意密钥权限与网络连通性）
三、确保热更新流程不中断
URL 变更后，原有拉取逻辑可能因认证、证书或协议差异失败，需同步校准：
- 若新地址启用 HTTPS + PAT（Personal Access Token），需在脚本中将 token 注入 URL：
https://TOKEN@new-domain.com/user/repo.git（注意避免日志泄露） - 若切换为 SSH，确认所有 ECS 上 ~/.ssh/id_rsa.pub 已添加至新平台的 deploy keys 或账户 SSH keys
- 临时绕过 SSL 验证（仅限内网可信环境）：
git -C /path/to/project config http.sslVerify false
四、验证与兜底机制
修复后必须闭环验证，防止“看似成功、实则静默失败”：
- 在一台 ECS 上手动触发一次完整热更新：拉取 → 构建（如需）→ 重启服务 → 检查健康接口返回
- 对关键分支（如 main/stable），执行 git ls-remote origin HEAD 确认能获取最新 commit hash
- 建议立即启用多远程备份机制：
git remote add backup https://gitee.com/user/repo.git
git push --all backup（后续可设定时同步）
