Question

我不清楚以下是什么意思（来自git submodule update docs）：

除非指定--rebase或--merge，否则
...将使子模块HEAD分离...

--rebase / --merge如何改变一切？

我的主要用例是拥有一堆中央存储库，我将通过子模块嵌入到其他存储库中。我希望能够改进这些中央回购，直接在他们的原始位置，或从他们的嵌入回购（通过子模块使用它们的那些）。

从这些子模块中，我可以创建分支/修改并使用推/拉，就像我在常规回购中一样，或者有什么需要谨慎的吗？
如何将引用的子模块从say（tagged）1.0提升到1.1（即使原始repo的头部已经是2.0），或者选择使用哪个分支的提交？

Answer 1

要更新每个子模块，您可以调用以下命令。（根据回购。）

git submodule -q foreach git pull -q origin master

您可以删除 -q 选项以完成整个过程。

Answer 2

要解决--rebase vs --merge选项：

假设您有超级回购A和子模块B，并希望在子模块B中完成一些工作。您已完成作业，并在调用后知道

git submodule update

你处于无HEAD状态，所以你现在做的任何提交很难回复。所以，你已经开始在子模块B

中的新分支上工作了

cd B
git checkout -b bestIdeaForBEver
<do work>

与此同时，项目A中的其他人已经决定最新和最好的B版本确实是应得的。出于习惯，您可以合并最近的更改并更新子模块。

<in A>
git merge develop
git submodule update

哦，不！你又回到了无头状态，可能是因为B现在指向与B的新提示或其他提交相关联的SHA。如果只有你：

git merge develop
git submodule update --rebase

Fast-forwarded bestIdeaForBEver to b798edfdsf1191f8b140ea325685c4da19a9d437.
Submodule path 'B': rebased into 'b798ecsdf71191f8b140ea325685c4da19a9d437'

现在B的最佳创意已经重新定位到新的提交，更重要的是，你仍然在B的开发分支上，而不是无头状态！

（ - somege将来自beforeUpdateSHA的更改合并到afterUpdateSHA到您的工作分支，而不是将您的更改重新定位到afterUpdateSHA。）

Answer 3

Git 1.8.2提供了一个新选项--remote，可以实现此行为。运行

git submodule update --rebase --remote

将从每个子模块的上游获取最新的更改，将它们重新绑定，并检查子模块的最新版本。正如here所说：

- 远程

此选项仅对更新命令有效。不使用超级项目记录的SHA-1来更新子模块，而是使用子模块的远程跟踪分支的状态。

这相当于在每个子模块中运行git pull，这通常正是您想要的。

（从the docs复制）

git子模块更新

4 个答案:

- 远程