Git子模块URL变更后deinit失效，sync生效的原因及疑问

问题场景 #

• 克隆仓库并切换到branch001，初始化子模块，操作正常；
• 切换到branch002，此时.gitmodules已更新子模块URL，但.git/config仍保留旧URL；
• 执行git submodule deinit -f --all后，.git/config的子模块条目被删除，重新执行git submodule update --init时拉取失败，报错无法找到指定提交；
• 执行git submodule sync可解决问题，但存在以下疑问：

疑问解答 #

1. 为何git submodule deinit无法重置子模块URL？ #

git submodule deinit的核心作用是移除本地主仓库中针对子模块的跟踪配置（即.git/config内的相关条目），同时清理子模块工作区与主仓库的关联，但它的设计目标不包含读取.gitmodules的新URL来更新配置，也不会修改子模块本地仓库的远程地址。它只负责“取消初始化”操作，不处理配置同步，因此无法重置子模块URL。

2. 旧子模块URL存储在何处？ #

旧URL除了曾存在于主仓库的.git/config，还保存在**子模块本地仓库的.git/config**中（路径为./<子模块路径>/.git/config，对应[remote "origin"]下的url字段）。第一次在branch001初始化子模块时，Git会将.gitmodules中的URL写入子模块本地配置，后续切换分支后，该子模块内部的配置不会自动更新。

3. 该存储为何优先级高于.git/config？ #

Git处理子模块远程地址的优先级为：子模块本地.git/config > 主仓库.git/config > 主仓库.gitmodules。原因是子模块本身是独立的Git仓库，自身的配置拥有最高优先级——子模块可能被多个项目引用，其远程地址配置应以自身为准，主仓库的配置仅作为引用时的初始设置，而非强制覆盖子模块自身配置。

4. git submodule deinit -f --all未删除子模块本地文件是否为Git Bug？ #

这不是Bug，属于设计预期行为。git submodule deinit仅移除主仓库对子模块的跟踪配置（.git/config条目），并将子模块工作区内容标记为未跟踪状态（解除主仓库与子模块的索引关联），但不会删除子模块的本地仓库文件（包括./<子模块路径>下的所有内容及内部.git目录）。若需彻底删除子模块本地文件，需手动执行rm -rf <子模块路径>操作。

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