不幸的是* Composer 不支持 Git 子模块，因为 Composer 的主要目标是提供类似的项目间依赖功能，尝试在 Composer 中复制子模块是毫无意义的。
我遇到了与您试图解决的相同问题，即开发一个库，同时开发使用该库的应用程序。有几种方法可以仅使用 Composer 来解决该问题。
为库目录创建符号链接
这是最快也是最肮脏的方法。只需执行作曲家更新即可在您的供应商目录中为库创建适当的目录，然后将其替换为包含库的目录中的符号链接。
显然这不太好，因为您可能会意外覆盖通过运行 Composer update 编辑过的代码。
使用 Composer 首选源选项
Composer 可以选择通过 Git 克隆下载源代码（--prefer-src）而不是下载 zipball（--prefer-dist) 这是默认值。这允许您编辑供应商目录中的源代码，然后通过 Git 提交。
例如假设您有一个需要其他库的项目symfony/yaml您想要修复其中的错误。您可以做的是：
composer update- 这将下载项目的所有依赖项。
composer update symfony/yaml --prefer-source- 现在将仅更新symfony/yaml目录位于供应商目录中。
修复bug，然后通过git提交。
使用 Composer 本地存储库
实际上，当我开发项目及其需求时，我的工作方式是使用 Composer 功能来显式设置存储库以用于解决依赖关系。例如如果您的代码位于：
/projects/library/
/projects/project/
在项目的 Composer 文件中添加存储库条目：
"repositories": [
{
"type": "vcs",
"url": "/projects/library/"
}
]
Running composer update现在将查看 /projects/library/ 中的 Git 条目，以解决对库的任何依赖关系，优先于 Packagist 或其他存储库中列出的依赖关系。
这确实意味着当您想要测试库代码中的更改时，您需要：
提交它，以便它有一个 Git 条目。
在项目目录中运行 Composer update 以获取最新版本。
但是您可以避免将提交推送到外部存储库，这很好，因为这意味着您不会推送可能不起作用的代码，并且意味着您可以离线工作，因为 Git 提交不需要互联网连接。
虽然这显然是最好的工作方式，但它仍然有点危险，因为很容易意外签入引用本地目录的composer.json版本，这显然会破坏其他人的项目。
为了避免这种情况，我制作了几个小脚本，i）备份我真正的composer.json文件，ii）添加一些本地存储库，iii）运行composer updateiv) 恢复真实的composer.json 文件。
本地更新.sh
cp -f composer.json composer.json.bak
php composerLocal.php
composer update
cp -f composer.json.bak composer.json
作曲家本地.php
<?php
$srcFile = file_get_contents("composer.json");
$hackFile = file_get_contents("composer.local");
$finalString = str_replace('"LOCALHACK",', $hackFile, $srcFile);
file_put_contents("composer.json", $finalString);
?>
本地作曲家
"LOCALHACK",
"repositories": [
{
"type": "vcs",
"url": "/projects/library1"
},
{
"type": "vcs",
"url": "/projects/library2"
}
],
然后放置"//": "LOCALHACK",在你的项目中的某个地方composer.json文件。跑步localupdate.sh现在可以安全地对本地存储库进行 Composer 更新，而不会提交 Composer.json 的错误版本。
只需用 Git 自己克隆即可
这就是我现在的工作方式：
i) 项目中的 Composer 更新
ii）进入vendors目录并删除我想要同时开发的库。
iii) 从您正在开发库的任何存储库中进行 Git 克隆，将其克隆到相应的供应商目录中。
Composer 理解 git 存储库，因此不会覆盖 git 克隆的目录（尽管它似乎对编辑库的composer.json 感到有点困惑）。
自己进行 git 克隆，可以让您完全控制安装的内容，并允许您从composer不知道的存储库或未标记的版本进行安装，而无需编辑项目中的composer.json。
这是自己进行 git 克隆的关键特征；通过不接触项目的composer.json，它是完全安全的，不可能签入已修改为使用本地/自定义存储库的composer.json。
对composer.json 文件的验证已加强，并且不再可能有"//": "LOCALHACK"文件中的条目。这也是 Composer 人员没有为 Composer 项目进行版本控制的另一个原因。
* 实际上，我认为 Git 子模块是一种愚蠢、愚蠢、愚蠢的实现，它以一种只会导致更多问题的方式“解决”一个难题，因此 Composer 不支持它们比“不幸”更“幸运”。显然其他人确实使用它们，并且对它们感到满意，所以这只是我的意见，但如果你使用 Composer，你不应该需要子模块。
