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