我本地计算机上的以下 2 个文件夹包含共享库/帮助程序：
上面的库应该是我后端的子模块...
...和我的前端：
到目前为止，一切都已配置并且可以正常工作！
此外，我有前端和后端的远程服务器。
现在我想得到以下信息：如果我在其中一个共享库中提交更改，我想通过一个 git push（后端、本地计算机上的前端和后端、服务器上的前端）将更改推送到所有 4 个存储库中。
如果这是不可能的：如果我在库中提交更改，我想通过一次推送至少将更改推送到我的 2 个本地目录中。如果我将本地目录之一的更改推送到远程服务器，则子模块的更改也应自动推送到远程目录。
共享库中的更改只能在共享文件夹中进行，而不能在后端或前端中进行！
谢谢你的帮助！
现在我想得到以下信息：如果我在其中一个共享库中提交更改，我想通过一次 git push（后端、本地计算机上的前端和后端、服务器上的前端）将更改推送到所有 4 个存储库中。
这对于简单的 git push 是不可能的。您不能将更改“推送”到带有工作副本的存储库 - 您只能推送到裸存储库。对于带有工作副本的仓库，您只能从其他地方提取。
使用子模块有点棘手，我已经尝试过像你之前所说的那样做一些事情。我完全放弃了让我的 git 子模块中的内容更通用并且能够作为独立的东西安装在系统上的想法。
像这样看待它 - 如果您的库中的代码与您的主存储库足够分离，那么将其视为自己的包并单独开发/部署它是合乎逻辑的。如果您的库中的代码严格依赖于您的主存储库，那么无论如何它都应该只是一个存储库。
并不是说没有子模块的情况 - 我仍然使用它们。如果你想使用它们，你必须遵守它们的规则：
这看起来很麻烦，但子模块与任何其他 repos 并没有什么不同。他们独立存在，你需要这样对待他们。此外，从父级的角度来看，子模块文件夹只是一个包含 sha1 哈希的文件。这些git submodule命令只是对父级引用的存储库进行操作的便捷脚本。
更新
虽然您不能在单个命令中使用纯 git 来执行此操作，但您可以编写一个 bash 脚本来为您完成大部分工作，您可以将它与 git 钩子组合以使其自动化。
它无法自动处理冲突解决，如果出现问题，您可能会试图找出 4 个单独的 repos 的状态。
我不会推荐这样的解决方案。它过于复杂且可能很脆弱，您必须涵盖的可能性数量才能使其健壮灵活且通用。