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