我很惊讶没有人提到使用git钩子来做到这一点!

只需将名为post-checkout和post-merge的文件添加到相关存储库的.git/hooks目录中，并将以下文件放入每个文件中:

#!/bin/sh
git submodule update --init --recursive

由于您特别要求一个别名，假设您希望为许多存储库使用这个别名，您可以创建一个别名，将这些别名添加到存储库的.git/hooks中。

从Git 2.14开始，你可以使用Git的pull - recursive -submodules(和你喜欢的别名)。

从Git 2.15开始，你可以设置submodule。递归为true以启用所需的行为。

你可以通过运行:

git config --global submodule.recurse true

正如其他人提到的，你可以很容易地设置:

git config --global submodule.recurse true

然而，如果你像我一样，有一个更复杂的.gitconfig设置(我的主~/。Gitconfig文件使用include来加载其他。Gitconfig文件)，你永远都不记得如何在命令行git配置格式和。Gitconfig格式之间转换，下面是如何将它添加到任何你的。Gitconfig文件中:

[submodule]
  recurse = true

我如何能够获得子模块和嵌套子模块更新的唯一方法:

git submodule update --remote --merge --recursive; git submodule foreach --recursive "(git add .; git commit -m 'SubmoduleSync'; git push; git pull;);" git add .; git commit -m 'SubmodulesSynced'; git push; git pull;

由于括号，我努力通过终端创建别名，所以我必须手动将此添加到.gitconfig全局:

[alias] supdate = "!git submodule update --remote --merge --recursive; git submodule foreach --recursive '(git add .; git commit -m 'SubmoduleSync'; git push; git pull;);' git add .; git commit -m 'SubmodulesSynced'; git push; git pull;"

对于如何自动运行命令或别名有什么建议吗?

Git配置——全局别名。pullall”!Git pull && Git子模块更新——init——递归

如果你想把参数传递给git pull，那么使用下面的代码:

git config --global alias.pullall '!f(){ git pull "$@" && git submodule update --init --recursive; }; f'

从Git 2.15开始，你可以设置submodule。递归为true以启用所需的行为。

事实上，你不需要这么做。

在Git 2.34 (Q4 2021)之前，在“Git clone——recurse-submodules”(man)之后，所有子模块都被克隆了，但默认情况下不会被其他命令递归。

与Git 2.34，和子模块。stickyRecursiveClone配置集，子模块。递归配置在“clone”创建的存储库中被设置为true，并带有“——Recurse -submodules”选项。

参见Mahi Kolla (24mahik)提交的48072e3(2021年8月14日)。 (由Junio C Hamano—gitster—在commit 6d09fc5中合并，2021年9月10日)

克隆:设置子模块。如果子模块，递归=true。stickyRecursiveClone启用 署名:Mahi Kolla

Based on current experience, when running git clone --recurse-submodules(man), developers do not expect other commands such as pull or checkout to run recursively into active submodules. However, setting submodule.recurse=true at this step could make for a simpler workflow by eliminating the need for the --recurse-submodules option in subsequent commands. To collect more data on developers' preference in regards to making submodule.recurse=true a default config value in the future, deploy this feature under the opt in submodule.stickyRecursiveClone flag.

警告:使用Git 2.37 (Q3 2022):

"git pull"(man) without——recursive -submodules=<arg> made submodule。递归优先于取回。recurseSubmodules错误，已在Git 2.37 (Q3 2022)中更正。

参见格伦·秋(chooglen)提交的5819417(2022年5月10日)。 (由Junio C Hamano—gitster—在commit ed54e1b中合并，2022年5月20日)

拉:不让子模块。fetch.recurseSubmodules 报告人:Huang Zou 资助人:菲利普·布莱恩 署名:Glen Choo

Fix a bug in "git pull"(man) where submodule.recurse is preferred over fetch.recurseSubmodules when performing a fetch (Documentation/config/fetch.txt says that fetch.recurseSubmodules should be preferred.). Do this by passing the value of the "--recurse-submodules" CLI option to the underlying fetch, instead of passing a value that combines the CLI option and config variables. In other words, this bug occurred because builtin/pull.c is conflating two similar-sounding, but different concepts: Whether "git pull" itself should care about submodules e.g. whether it should update the submodule worktrees after performing a merge. The value of "--recurse-submodules" to pass to the underlying git fetch". Thus, when submodule.recurse is set, the underlying "git fetch"(man) gets invoked with --recurse-submodules[=value]", overriding the value of fetch.recurseSubmodules. An alternative (and more obvious) approach to fix the bug would be to teach "git pull" to understand fetch.recurseSubmodules, but the proposed solution works better because: We don't maintain two identical config-parsing implementions in "git pull" and git fetch". It works better with other commands invoked by "git pull" e.g. 'git merge'(man) wont accidentally respect fetch.recurseSubmodules.