我的个人存储库有一些存储库作为子模块。和以下命令
$ git submodule foreach git pull origin master
在进入ruby存储库后立即面临以下结果，因为ruby存储库似乎没有master分支，"git pull"停止了。
Entering 'rails'
From git://github.com/rails/rails
* branch master -> FETCH_HEAD
Already up-to-date.
Entering 'roo'
From git://github.com/hmcgowan/roo
* branch master -> FETCH_HEAD
Already up-to-date.
Entering 'ruby'
fatal: Couldn't find remote ref master
Stopping at 'ruby'; script returned non-zero status.
所以我的问题是what should I do to git pull for all of submodules only by git command?我应该为此编写脚本吗？我希望git提供的一个命令行就能做到这一点。
只需将|| true添加到子模块命令：
git submodule foreach 'git commit -m "my commit message" || true'
git子模块通常处于分离的HEAD状态，因此它们上的git pull在合并阶段无法理解您的意思。如果您所要做的只是将最新的更改获取到存储库中，请尝试git submodule foreach git fetch。如果您想将每个子模块master更新为其各自的origin/master，则可以使用git submodule foreach git checkout master; git submodule foreach git merge origin/master进行后续操作。
然后，当然，您需要决定您希望主存储库使用每个子模块的哪个版本（我不建议一直盲目使用origin/master——它可能不稳定——最好选择一个已知的好标签或其他东西），检查子模块中的这些版本，并在主存储库中使用适当的git add和git commit。
Git 2.18（2018年第二季度）可能会通过改进影响git submodule pull的git submodule update来避免该错误。
"CCD_ 14"；尝试两种不同类型的"；CCD_ 15"；针对上游存储库来获取子模块路径上绑定的提交，但如果第一种（即正常的获取）失败，它会错误地放弃，从而导致第二种"提交"；最后的手段"；一个（即通过对象名称获取精确的提交对象）无效
这一点已得到纠正。
请参阅Stefan Beller（stefanbeller）提交的e30d833（2018年5月15日）
（由Junio C Hamano合并——gitster——提交于173ddd，2018年5月30日）
git-submodule.sh：更努力地获取子模块
这是fb43e31的逻辑连续体（子模块：更加努力fetch通过直接获取sha1需要sha1，2016-02-23，Git 2.8.0），并修复了它，因为一些假设不正确。
提交状态：
如果
$sha1不是默认获取的一部分。。。fail我们在这里假设fetch_in_submodule只有在服务器端不支持sha1获取时才会失败。还有其他故障，为什么这样的提取可能会失败，比如
fatal: Couldn't find remote ref HEAD如果远程端不宣传HEAD，而我们没有有一个本地获取参考规范。
协议规范允许不公布HEAD，例如，如果HEAD指向未出生的分支。
当提取子模块时，可能会出现没有本地提取refspec的情况简单地说，gitclone不会设置fetch-refspec。
因此，请通过忽略首先获取，而是依赖于以下
is_tip_reachable看看我们是否再次尝试抓取。
注意：Git 2.22（2019年第二季度）改进了子模块获取的错误消息
参见Jonathan Tan（jhowtan）提交的bd5e567（2019年3月13日）
（由Junio C Hamano合并——gitster——提交32414ce，2019年4月9日）
子模块：清楚地解释第一次尝试失败
使用
--recurse-submodules克隆至少包含一个HEAD指向未出生分支的子模块，克隆像这样的东西：Cloning into 'test'... <messages about cloning of superproject> Submodule '<name>' (<uri>) registered for path '<submodule path>' Cloning into '<submodule path>'... fatal: Couldn't find remote ref HEAD Unable to fetch in submodule path '<submodule path>' <messages about fetching with SHA-1> From <uri> * branch <hash> -> FETCH_HEAD Submodule path '<submodule path>': checked out '<hash>'换句话说，首先，在没有散列参数的情况下完成提取（即，HEAD的获取），从而产生"HEAD"；CCD_ 25"；错误然后，在给定一个散列的情况下进行一次获取，获取成功。
此提交改进了通知，使其更清楚地表明我们正在重试fetch，以及以前的消息（特别是致命错误from fetch）并不一定表示整个命令失败。
注意，在Git 2.34（2021年第四季度）中；CCD_ 26"（man）在C中继续。
参见Atharva Raykar提交的c51f8f9（2021年8月24日）（tfidfwastaken）
（由Junio C Hamano合并——gitster——提交e78db9d，2021年9月20日）
submodule--helper:从C运行更新过程导师：Christian Couder
导师：Shourya Shukla
签字人：Atharva Raykar
添加一个新的子模块--helper子命令
run-update-procedure，如果子模块的SHA1与超级项目所期望的不匹配，则该命令将运行更新过程。
这意味着上述is_tip_reachable shell方法已不存在。
Git 2.36（2022年第二季度）也进行了同样的C重写；CCD_ 32"（人）。
请参阅Glen Choo（chooglen）的提交c9d2562、提交104744f、提交97cb977、提交29a5e9e、提交1012a5c、提交e441966、提交1a0b78c、提交f7bdb32（2022年3月4日）
请参阅Atharva Raykar（tfidfwastaken）的提交3ce52cb、提交5312a85、提交a77c3fc（2022年3月4日）
参见提交ed9c848，提交aca8568（2022年3月4日），作者：Ævar ArnfjörğBjarmason（avar）
（由Junio C Hamano合并——gitster——提交7649bfb，2022年3月23日）
Git 2.39（2022年第四季度）的重写对手，其中包括准备删除git-submodule.sh并用内置代码替换它。
请参见Ævar ArnfjörğBjarmason（avar）提交的提交69d9446、提交1b6e200、提交64f48ad、提交82ff877、提交46e87b5、提交d50d848、提交435285b、提交44874cb、提交cc74a4a（2022年11月8日）
（由Junio C Hamano合并——gitster——于2022年11月23日提交1107a39）