我有几个问题，考虑到这一点，下面的答案是相当一般的。如果你回答我的问题，我很乐意更新它。

• composer在更新时会拉取repo吗？还是重新克隆repo？（它甚至会做更新吗？）
• 如果它重新克隆，那么使用它进行更新将有可能覆盖您在这些子Repos上的工作树（仅用于安装或一起删除）
• 如果它不做更新（或者依赖递归--见下文），那么它就给你的项目增加了不必要的复杂性（删除它并使用下面的选项之一）
• composer是否真的在做依赖管理（比如递归查找嵌套的依赖）？或者只是简单地将git项目克隆为子文件夹？
• 如果是，那么是的，子模块可能不适合您的情况，因为它们是一个替代的依赖管理系统，但是如果您的子项目也使用子模块来管理它们的依赖，那么使用git clone --recursive应该也可以管理它们
• 是否希望主项目跟踪子项目的新更改？
• 如果是：请查看选项2：子资料库
• 否则：尝试选项#1：子模
• [还有第三个选项，我将链接到，但我还没有使用它，所以不能详细解释（评论/编辑赞赏）]

选项1：Submodules

您也可以通过cd LOCAL_DIR_NAME_I和普通的git命令管理单个子模块

1.设置：

git submodule add REMOTE_URI_1 LOCAL_DIR_NAME_1
...
...
git submodule add REMOTE_URI_N LOCAL_DIR_NAME_N
git commit -m "Add submodules..."

1.克隆（主项目）
git clone MAIN_URI REPO && cd REPO && git submodule update --init --recursive
--init会在执行更新之前将配置从.gitmodules复制到.git/config（如果需要），--recursive会在每个子模块中递归执行该操作。
或
git clone --recursive MAIN_URI
--recursive告诉git在克隆时更新和初始化所有子模块

• 正在更新（将保留未保存的更改）
• 本地副本没有未推送的更改（默认情况下更新所有子模块）：

git submodule update [LOCAL_DIR_NAME_I ... LOCAL_DIR_NAME_J]

• 本地副本具有未推送的更改（默认情况下更新所有子模块）：

git submodule update --remote --rebase [LOCAL_DIR_NAME_I ... LOCAL_DIR_NAME_J]

• 发布/推送

这将首先尝试子模块推送，如果成功，则执行主项目推送
git push --recurse-submodules=on-demand

选项2：Subrepositories

您说您在使用此方法时遇到问题，但我不明白是什么问题。如果可能，请详细说明。

(the git的书也提到过次回购，但我现在一辈子都找不到它在哪里;如果你找到了请告诉我）
1.设置：
注意：主存储库不会跟踪对子存储库的.git的更改，只会跟踪文件主题本身的更改

目录名后面的斜杠（/）对于避免创建子模块非常重要

git clone REMOTE_URI_1 LOCAL_DIR_NAME_1 && git add LOCAL_DIR_NAME_1/
...
...
git clone REMOTE_URI_N LOCAL_DIR_NAME_N && git add LOCAL_DIR_NAME_N/
git commit -m "Add subrepos..."

如果使用Composer：（它会为您执行克隆），您可以简单地执行添加和提交操作，但也许您也可以配置Composer来执行此操作。

1.管理

通过以下方式管理单个子表示：'cd LOCAL_DIR_NAME_N'并使用普通git命令

请记住，对子存储库文件的更改将由主存储库跟踪

这里最大的问题是克隆（如果你希望协同器能够在子项目上工作），因为你的subrepo.git文件没有被跟踪。remote.info在每个存储远程文件的subrepo中包含一个文件www.example.com应该可以解决这个问题。然后在你的主repo中添加一个脚本，为每个子目录cd SUBDIR && git init && cat remote.info | xargs git remote add origin做这个。这取决于Composer正在做什么（请参阅上面的问题）您可能需要将composer update命令添加到此脚本中

∮ ∮ ∮
我对这种方法的微妙之处没有完全的信心，所以我将直接链接到它
Try this link for a bit of a tutorial

选项#N：随你怎么说

当然，你可以设置许多其他的工作流，在某些情况下可能会更简单。例如，你可以坚持使用Composer进行部门管理，并在主项目之外克隆子项目。在主项目中创建未跟踪的符号链接，以允许在处理主项目时轻松访问这些文件。这可以通过脚本自动完成（就像批量推送所有这些repos一样）你甚至可以解析composer.json，自动为新的（基于git的）依赖项执行此操作。
注意：在我看来，你根本不需要使用Composer。如果这个假设是不正确的，上面的3个选项可能都不能解决你的问题。

@DylanYoung已经提供了一个很棒的答案，但是当我开始研究如何在Git中使用Bedrock时，我也遇到了同样的问题，我想我也许可以提供一些额外的想法，对偶然发现这篇文章的人来说会很有用。
和Dylan一样，我得出的结论是，composer不仅是一个不必要的并发症，而且很可能是一个灾难的配方，这有各种各样的原因，但最主要的一个是如何处理商业插件Bedrock gives some options并演练了对每个商业插件使用Git repos，但是他们忽略了你实际上是如何更新插件的，唯一的可能是在每次更新时从开发人员那里手动下载zip文件，然后将其添加到它的“git repo，”然后通过Composer被重新拉入项目中。
澄清一下，Composer看起来是一个很棒的工具，但更适合于“合适的”PHP项目，WordPress肯定没有资格。Bedrock更适合于“合适的”PHP --通过Roots提供的各种其他工具（Acorn，Sage等）将WordPress与Laravel集成在一起。但如果你没有使用这些工具，那么你真的不需要Composer。
但是如果你不使用Composer，你怎么做更新！？通过WordPress自己的Composer：WP Admin Updater，或者对于面向git的工作流，WP-CLI. WP-CLI允许指定补丁、次要和主要更新版本，以及更多--特别是通过第三方WP-CLI包。此外，我怀疑它可以正确处理插件更新，插件更新有时会更改DB（ composer 对此一无所知）。最后，你当然可以有一个脚本/自定义包，它可以自动地逐个更新插件，并将它们提交给git，同时显示版本号-这将允许容易地跟踪改变以及在必要时恢复提交/更新。
对于任何自定义插件/代码，你可以将其包含在monorepo中，或者像Dylan在他精彩的回答中建议的那样使用子模块。我可能会选择后者，因为我可能最终会使一些私有插件商业化。子模块同样可以用于任何你正在贡献的具有公共git repo的插件。
我仍然会使用Bedrock，因为我喜欢它构建一切的方式，但除此之外，我会坚持使用WP + Git。
我希望这能为将来在这个问题上挣扎的人节省一些时间。我浪费了几天时间试图弄清楚这一点，直到我意识到Composer是一个寻找问题的解决方案。
编辑：一个额外的注意-许多WP插件使用Composer为自己的开发过程，并捆绑在插件包.这是一个完全独立的事情，因为插件是一个独立的项目，而整个WP网站是一个项目的项目.