以一个项目为例，主存储库 M 中的可执行源和几个子模块 S1、S2 等中的依赖库。决定将可执行文件中的一些代码迁移到子模块 S1 中的库中其他项目通常可以访问。我们将主存储库和子模块都分支，迁移过程的第 1 步是简单地将 N 个文件从 M 中的目录移动到 S1 中的特定目录（具有不同的路径）。天真的方法是简单地从 M 中 git rm 文件，将它们移动到 S1 中的新目录，cd 到子模块，然后 git add 它们。问题当然是这些文件的所有历史记录都丢失了。这不是一个大问题，因为我认为例如 pull-merge 不会跟踪从 M 中的文件到 S1 中的新家的更改，
所以这就是我的问题：有没有比简单的 rm-and-add 更好的方法来完成从 M 到 S1 的文件迁移，这样至少可以保留文件的历史记录。如果它在 M 之内，当然可以简单地使用 git-mv。我已经看到了一些在任意存储库之间移动文件的公式，但是 A，我发现它们几乎不可能遵循，而 B，我希望主模块和子模块之间的托管关系可能会使它更容易或更优雅地完成。如果答案是出于这些目的，M 和 S1 只是两个任意不同的存储库，那么这里的某个人可能会以比我在其他地方看到的更好的方式列出这些步骤并进行解释。这实际上是我现在正在研究的一项任务，因此我们将不胜感激任何相关的反馈。
编辑：合理地建议这是Git: Moving files into an existing submodule 的副本。这似乎是真的，这并不让我感到惊讶，这已经被提出了，但对于一个对 git 有相当基本了解的读者来说，答案是相当简洁的。我希望通过对所涉及命令的更完整描述来分解这些步骤。
Edit2：在我看来，所谓的 dup（以及其他类似问题和答案）的答案对我不起作用的原因有两个。一方面，为了了解正在做的事情，我需要阅读所有这些内容，只是因为我需要加深我对 git 正在发生的事情的模型。那在我身上。但是在完成了这些之后，现在了解了这些拆分和合并方法正在发生的事情，我意识到我试图解决的问题更深入——事实上，如此之深，以至于我开始意识到它可能git 无法交付的独角兽。
当你有一个单一的存储库 - 没有子模块时，你可以移动一个文件git mv，并且它为系统提供了更多信息，而不是简单地从一个位置删除并添加到另一个位置。它保留了历史，但我相信它还允许 git 跟踪在移动文件中所做的更改，无论它们在其他本地存储库中的什么位置。因此，如果我将我的文件移动到一个分支中，而其他人在他们自己的文件视图中修改文件并提交并推送这些更改并将它们合并到主分支，那么我相信 git 有足够的会计信息，当我提取这些更改时，它们在我的存储库视图中被合并到新位置的文件中。这是一个比仅仅保存历史更大的附加值（在我看来）。如果我从主存储库中删除文件并将它们添加到子模块中，它们在新位置将没有历史记录，但是他们在旧位置的生活历史仍然可以通过已删除文件的“幽灵”来检索。不方便，但不是灾难性的。但是，如果有一种方法可以管理来自其他开发人员视图的更改并将它们定向到存在于子模块中的文件，那将是惊人的。太神奇了，这似乎超出了 git 的能力范围。总而言之，我想我正在寻找一个可以跨存储库工作的神奇“git mv”，现在我想起来，我怀疑这样的事情是否存在。太神奇了，这似乎超出了 git 的能力范围。总而言之，我想我正在寻找一个可以跨存储库工作的神奇“git mv”，现在我想起来，我怀疑这样的事情是否存在。太神奇了，这似乎超出了 git 的能力范围。总而言之，我想我正在寻找一个可以跨存储库工作的神奇“git mv”，现在我想起来，我怀疑这样的事情是否存在。