简短的回答：
cd ProjectFooBarCommoneSubmodule
git checkout master
<Do your editing>
git commit --all -m "Lots of fixes"
git push submodule_origin master
cd ..
git add ProjectFooBarCommoneSubmodule
git commit -m "Bumped up the revision of ProjectFooBarCommoneSubmodule"
git push origin master
较长的一个：
Git子模块是一种依赖机制，其中主项目（比如A）在子项目（比如B）中定义了一个指定的修订版，它将用于构建项目A。为了使工具有用，行为必须是可预测的从 A:s 的角度来看。依赖关系不能更改，除非有人决定将更改合并到项目 A。如果项目 B:s 更改自动导入，则可能会发生各种令人讨厌的事情，其中编译错误可能是最好的错误，因为 A 会立即注意到失败。这就是为什么 B:s 的头部保持分离状态。
B 的状态存储在 A 中（签出git submodule status），并且必须在 A 中完成并提交修订更改，以使其生效。这就是上面示例中发生的情况，A 更改了存储在 repo 中的修订号，并将版本提升到最新版本。该过程也必须在其他主仓库中重复，因此没有自动“使用主”开关 AFAIK。
顺便提一句。关于子模块的Git 书籍章节和子模块手册页包含许多关于子模块的有用信息，包括正常使用和典型陷阱。值得一试。
编辑：我会尝试更好地解释这一点
我冒昧地在我的 github 帐户上创建了示例项目。提交是无意义的并且包含垃圾，但设置应该没问题。请检查它以跟随。
ProjectFoo 和 ProjectBar 共享公共子模块中的代码。
ProjectFooBarCommoneSubmodule:master 是6850e4e4c1fac49de398
在 ProjectFoo 中：
git submodule status
-6850e4e4c1fac49de39890703f21486ca04b87a0 常见
在项目栏中：
git submodule status
-6850e4e4c1fac49de39890703f21486ca04b87a0 常见
所以两者都指向同一个修订版，对吧？这里的诀窍是看到，ProjectFoo 和 ProjectBar 指向修订版（6850e4e4c1fac49de39890703f21486ca04b87a0）而不是分支（主），尽管它们是同一件事。第一个是分离的头，另一个是命名的分支。
如果您想对 ProjectFooBarCommoneSubmodule 进行一些修复，您可以转到例如 ProjectFoo 中的子目录，然后选择分支而不是修订：
git checkout master
<Do your coding and pushing here>
然后上一个目录，检查 git 子模块状态。它应该告诉你，你现在不同步了。例如
git submodule status
+e24bd2bf45d52171a63b67ac05cd4be0ac965f60 通用（heads/master-1-ge24bd2b）
现在你可以做一个 git add，设置对这个特定提交的引用（ge24bd...），做一个提交，然后子模块引用指向这个修订，它也恰好是 ProjectFooBarCommoneSubmodule 上的主。
现在您还需要更新 ProjectBar 中的引用。转到 ProjectBar/common，然后执行 git fetch origin（这是一个快进合并），执行
git checkout master
cd ..
git add common
git commit -m "Bumped up the revision"
git push origin master # to publish the revision bump to everybody else
因此，与任何 git 存储库一样，您不需要在一个分离的头上工作。您可以在 master 上工作，也可以创建一个命名分支。无论哪种方式，请确保上游包含 ProjectFooBarCommoneSubmodule 更改，否则如果 ProjectFoo 和 ProjectBar 引用不存在的内容，您将破坏它们。希望这能更好地解释它