如何提交对子模块而不是其父模块的更改？

如何解决如何提交对子模块而不是其父模块的更改？

我创建了一个存储库 A original。

然后我创建了存储库 B original。

我将 A original 添加到 B original 作为 A submodule。

我对 A submodule 中的 B original 进行了更改，但我不想将更改从 A submodule 推送到 A original。

是否可以将更改推送到 A submodule 而不必将它们推送到 A original？然后是否可以将来自 A original 的更新合并到 A submodule 中？

子模块是否是一个坏主意，更合适的方法是什么？？

解决方法

子模块是一个 Git 存储库。

一个 Git 存储库只不过是一个提交的集合¹。这意味着如果你想保留一些东西，你必须把它放到一个提交中。²

超级项目——使用第二个 Git 存储库的 Git 存储库，从而将第二个 Git 存储库转换为相关子模块——是它自己独立的 Git 存储库。在这种情况下，A original 是您的超级项目。它有提交，并且要坚持下去，您必须将其放入提交中。但是当 A original 引用某个子模块时，它在这里所做的只是存储一个 Git 哈希 ID。 这个哈希 ID 是子模块 Git 中某个特定提交的“真实名称”存储库.³

是否可以将更改推送到 [子模块 Git 存储库] 而不必将它们推送到 [超级项目]？

这个问题有点格式错误，因为我们实际上并没有推送更改。 git push 推送的是提交。提交不是更改：它们是快照。不过，这个概念是合理的：您进行一些更改，然后提交它，即通过获取更改的源并将它们转换为快照来制作新快照。

如果您在某个存储库中进行新的提交——无论“类型”的存储库可能是：超级项目、子模块还是独立的——并且您希望这些提交可供其他人使用，您不仅可以 em> 推动它们，你经常必须推动它们。将它们提供给其他人的唯一其他方法是让其他人获取/拉取您自己的计算机的访问权限。这往往是一项艰巨的工作，这就是为什么我们大多将它放在托管服务提供商（如 GitHub 或 Bitbucket）上的原因。

子模块的棘手之处在于，如果您确实对子模块 Git 存储库进行了更改，那么您应该：

1. 进行一次或多次新提交；
2. 将这些提交提交到其他人可以看到的地方（例如，git push 将它们发送给您的托管服务提供商）；
3. 返回到您的超级项目存储库并使用那里的 Git 工具创建一个新快照：一个显示使用新的子模块提交。

你也可以在这个超级项目快照中包含其他更改，但关键的变化是这个新的提交在超级项目说使用新的提交在子模块 .

然后是否可以将来自 [超级项目] 的更新合并到 [子模块] 中？

否：超级项目没有对子模块的更新。超级项目是一个单独的 Git 存储库。它所做的只是引用子模块中的一些特定提交。由于超级项目只是说“从子模块 H 中获取提交 X”（对于某些提交哈希 ID H），因此实际上没有什么可以合并。

子模块是提交的集合。只要它包含一个带有哈希 ID H 的提交，这就是超级项目所需要的；超级项目可以说的所有内容是“get me hash H”，或“get me hash I”，或“get me hash J”，或其他任何内容.

每个仓库都是一个 Git 仓库：

• 子模块是一个 Git 存储库：提交的集合（加上它拥有的任何其他小东西）。它只“知道”它是一个子模块，因为超级项目本身克隆了它，并且因为超级项目 Git 不断进入子模块并命令它：检查提交 _____（用一些原始哈希 ID 填写空白） .

• 超级项目是一个 Git 存储库：提交的集合（加上它拥有的任何其他小东西）。它只“知道”这是一个超级项目，因为它有一个提交说在必要时克隆子模块，然后检查提交_____（用一些原始哈希 ID 填写空白）。克隆指令位于名为 .gitmodules 的文件中；这些也可能会复制到您的 .git/config。其余的——哈希 ID 和克隆的路径——在超级项目的每个提交中。

这就是子模块的全部内容。嗯，好的，有一大堆交互，主要在 git submodule 中编码，结果来自上述，但这是超级项目/子模块对的本质。请注意，子模块 Git 存储库本身可以是一个超级项目，即它可以拥有自己的子模块。它所要做的就是列出一些要克隆的 Git 存储库，以及一些要检查的提交哈希 ID。

---

¹还有多少，取决于存储库的类型：--bare 存储库是提交和名称数据库（分支名称、标签名称等）的集合；非裸存储库还提供工作树。工作树不在存储库中，但它是您查看文件的位置，因此这非常重要。 ? 请记住，虽然 Git 提供了一个目录（或文件夹，如果你喜欢这个术语）在中工作，但该文件夹（目录）实际上并不在存储库中，它就在旁边。

²你放在工作树中的东西通常也会留下来——有很多注意事项——但因为它们紧挨着，而不是在，存储库，其他 Git 克隆将无法看到它们。

³分支名称是一种可更改的提交别名：它们可以让您找到一个提交，但有人可以稍后更改分支名称，以便你发现了一个不同的提交。超级项目 Git 坚持找到正确的提交，所以它不持有可能改变的分支名称：它持有一个无法改变的哈希 ID。