使用 Composer 时如何处理在另一个存储库中的存储库？

Question

我有一个项目，我使用 Git 在这个项目中进行版本控制。在这个项目中，我必须添加一些库作为依赖项（更具体地说是 PHPUnit 和 Guzzle）。要求说这些库必须存在于我的项目的文件夹中，并且我必须使用 composer 来安装/更新它们。

所以我这样做了，我的目录结构看起来像这样：

project
|----- .git
|----- libs
        |---- guzzle
                |---- .git
        |---- phpunit
                |---- .git

所以guzzle 和phpunit 文件夹都有一个单独的.git 文件夹。这是因为据我所知，composer 从 github 克隆了 master 分支，以便检索这些库的源代码。

所以我对远程存储库进行了提交+推送。但是，当其他人从该存储库中提取时，libs/guzzle 和 libs/phunit 文件夹中包含的文件不会出现在该人的工作目录中。

我认为这是因为有 2 个 .git 文件夹。

我该如何解决这个问题？我尝试在作曲家的文档中搜索一种在composer.json 中指定的方法，以便仅获取最后一个快照。但我找不到任何东西。

我也考虑过删除.git 目录，但如果我尝试在几个月内执行composer update，这不会破坏一切吗？

过去有没有人遇到过这种问题？你是怎么解决的？

Answer 1

显然，正如here 所述，我正在尝试做的是一个坏主意。我将不得不找到另一种安装/使用这些库的方法。

Answer 2

我有一些cmets和解释。

首先，您对 Composer 的使用创建了 git clone 人工制品。虽然这也不是很糟糕，但应该避免这种情况，因为克隆活动项目的 repo 通常比安装已发布版本需要更多的数据。

如果可以，请尝试使用--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 以从互联网上获取这些依赖项。这也适用于执行检出的部署脚本。