这是怎么发生的：
那么我该如何解决这个问题？当我回到一个从未存在的提交时，为什么 git 没有删除该文件夹。
我试过了：
git submodule update 在主仓库中。git reset --hard 在子模块的仓库中。git reset --hard 在主仓库中。没有什么可以删除它。我不想手动删除它，因为那不是 git 方式。
【问题讨论】：
标签： git git-submodules git-revert
那么我该如何解决这个问题？
从工作树中手动删除所有子模块文件：例如rm -rf submodule。
当我返回一个从未存在的提交时，为什么 git 没有删除该文件夹。
子模块很乱。
请记住，Git 中的子模块实际上只是另一个 Git 存储库。这个其他 Git 存储库完全独立于您的主（超级项目）存储库。或者更确切地说，它会是——你只有两个单独的克隆，并排，它们之间根本没有交互——除了你已经将子模块克隆插入到 的工作树中。超级项目。而且，在这个过程中：
在现代 Git 中，存储库本身被“吸收”到超级项目的存储库目录中（因此没有 .git 子文件夹，而是一个 .git 文件 在子模块签出提交的工作树副本中）。
超级项目的 Git 在超级项目的配置（不仅仅是.gitmodule 文件）和一些提交中记录关于子模块的内容。特别是，在子模块应该在某个特定哈希 ID 处签出的提交中，哈希 ID 本身在每个提交中存储为 gitlink 条目。
超级项目的 Git 将 cd-ing 保留到子模块中并执行 git checkout <hash-id> 分离子模块中的 HEAD。 （确切地何时这样做是另一个问题；这取决于您是否启用了子模块递归。）
一般来说，子模块是（大部分）独立存储库这一事实会阻止超级项目 Git 完全删除它。在这种特殊情况下，它可能应该继续删除它作为“将子模块更新为正确提交”的一部分，因为相关子模块中的“正确”提交是“没有提交全部 - 从工作树中删除子模块”。在过去，在 Git 将 .git 目录吸收到超级项目之前，这实际上会破坏子模块存储库，这会很糟糕。1 在现代 Git 中，它不会（一旦子模块.git 目录至少被吸收了），所以它可以工作。
1在许多情况下，它是无害的，但需要重新克隆。但是假设您通过 (1) 在您将 in 设置为子模块的新分支上进行子模块提交来提交超级项目； (2) 退出子模块回到超项目，更新索引gitlink条目，记录子模块中新的hash ID； (3) 进行新的提交。您现在有一个子模块提交，它不会被推送到任何地方，但可以并且应该在超级项目提交被推送之前被推送。
现在您已完成所有设置，您决定查看历史提交。您在超级项目中 git checkout <hash>，并且历史提交 没有 已签出子模块。您将submodule.recurse 设置为true 或使用了git checkout --recurse-submodules，以便超级项目将子模块带到正确（缺少）提交，并删除子模块。
由于.git 目录确实存在于子模块中（在子模块的工作树内），这完全、不可撤销地破坏了您在子模块中所做的提交，在您在那里所做的分支上，即你还没有推。所以这个不能做。
现在.git 目录本身存在于其他地方，从超级项目的工作树中删除子模块主体不会损害子模块存储库。所以现在，这种移除方式是安全的。将超级项目恢复到最新的提交可以简单地恢复子模块的工作树，检查由子模块的存储库分支（仍未推送）受 GC 保护的提交。
【讨论】：