我有一个项目，我使用 Git 在这个项目中进行版本控制。在这个项目中，我必须添加一些库作为依赖项（更具体地说是PHPUnit和Guzzle）。要求说这些库必须位于我项目的文件夹中，我必须使用 composer 来安装/更新它们。
所以我这样做了，我的目录结构看起来像这样：
project
|----- .git
|----- libs
|---- guzzle
|---- .git
|---- phpunit
|---- .git
因此，guzzle 和 phpunit 文件夹都有一个单独的.git文件夹。这是因为，据我所知，作曲家从 github 克隆了主分支，以便检索这些库的源代码。
所以我在远程仓库上做了一个提交+推送。但是，当其他人从该存储库拉取时，libs/guzzle和libs/phunit文件夹中包含的文件不会出现在该人的工作目录中。
我认为这是因为 2 个.git文件夹。
我该如何解决这个问题？我尝试搜索作曲家的文档，以寻找一种在composer.json中指定的方法，以便仅获取最后一个快照。但我什么也找不到。
我也考虑过删除.git目录，但是如果我尝试在几个月内进行composer update，那不会破坏一切吗？
过去有人遇到过这种问题吗？你是怎么解决的？
显然，正如这里提到的，我想做的是一个坏主意。我将不得不找到另一种安装/使用这些库的方法。
我有一些评论和解释。
首先，您使用作曲家创建了git clone伪影。虽然这并不完全坏，但应该避免，因为克隆活动项目的存储库通常比安装已发布版本要多得多。
如果可以的话，尝试使用--prefer-dist。这将下载该版本的ZIP文件，而不是从Github克隆。请注意，此选项是稳定版本的默认设置，这使我进入下一点......
请使用稳定版本。如果可以避免，请不要使用dev-master版本。你提到使用PHPUnit和Guzzle。两者都以您可以使用的稳定版本发布。做吧。使用不稳定的开发版本对这两个库没有任何好处，除非你绝对需要一个功能。使用不稳定版本的问题可能不会立即显示出来。但是想想半年后会发生什么。有人更新你的依赖项指向dev-master，现在指向从那时起发生的任何事情。PHPUnit 或 Guzzle 可能已经有一个新的主要版本，其中包含不兼容的更改。现在，您的项目不必要地中断了。
另一件事是要求将外部库放在定义的文件夹中。这是可行的，但实际上不应该这样做。Composer 确实适用于任何文件夹，但我在顶级目录中看到composer.json的通常反应是期望获得一个包含autoload.php的vendor文件夹。更改此设置需要向新开发人员提供更多解释，他们可能也希望 Composer 尽可能默认地工作。因为没有理由将 Composer 管理的依赖项放在任何地方，所以最好将它们放在每个人都期望它们的位置。如果不需要，请不要更改vendor文件夹。
最后一点是：提交你的composer.lock，但不要提交vendor文件夹。这是因为供应商文件夹可能包含外部库使用的源代码管理系统的跟踪，这些跟踪可能会混淆项目源代码管理。正确的工作流程是提交composer.lock，每个签出你的项目的人都必须运行composer install才能从互联网上获取这些依赖项。这也适用于执行签出的部署脚本。