0

I have a project and I use Git for doing version control in this project. Within this project I have to add a few libraries as dependencies (more specifically PHPUnit and Guzzle). The requirements say that these libraries have to live in a folder of my project and I have to use composer to install/update them.

So I did that and my directory structure looks something like this:

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

So the guzzle and phpunit folders both have a separate .git folder. This is because, as far as I can tell, composer makes a clone of the master branch from github in order to retrieve the source code of these libraries.

So I did a commit+push on a remote repository. However, when someone else pulls from that repository, the files contained in the libs/guzzle and libs/phunit folders do not appear in that person's working directory.

I'm thinking this is because of the 2 .git folders.

How can I fix this ? I tried searching the documentation of composer for a way to specify in composer.json to get ONLY the last snapshot so to speak. But I couldn't find anything.

I also thought about deleting the .git directories, but won't that break everything if I try to do a composer update in a few months ?

Did anyone have this sort of problem in the past ? How did you solve it ?

4

2 回答 2

2

显然我想要做的是一个坏主意，如此处所述。我将不得不找到另一种安装/使用这些库的方法。

于 2013-10-21T12:15:28.480 回答
1

我有一些意见和解释。

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

--prefer-dist如果可以，请尝试使用。这将下载该版本的 ZIP 文件，而不是从 Github 克隆。请注意，此选项是稳定版本的默认选项，这让我想到了下一点……

请使用稳定版本。dev-master如果可以避免，请不要使用版本。您提到使用 PHPUnit 和 Guzzle。两者都以您可以使用的稳定版本发布。去做吧。这两个库使用不稳定的开发版本没有任何好处，除非你绝对需要一个特性。使用不稳定版本的问题可能不会立即显示出来。但是想想半年后会发生什么。有人更新了指向 的依赖项dev-master，它现在指向从那时起发生的任何事情。PHPUnit 或 Guzzle 可能有一个新的主要版本，其中包含不兼容的更改。现在你的项目不必要地中断了。

另一件事是将外部库放在定义的文件夹中的要求。这是可行的，但实际上不应该这样做。composer.jsonComposer 确实适用于任何文件夹，但我对在顶级目录中看到 a 的通常反应是期望得到一个vendor包含autoload.php. 更改这一点需要对新开发人员进行更多解释，他们可能还希望 Composer 尽可能默认工作。因为没有理由将 Composer 管理的依赖项放在任何地方，所以最好将它们放在每个人都期望它们的地方。如果不需要，请不要更改文件夹。vendor

最后一点是：提交你的composer.lock，但不要提交vendor文件夹。这是因为供应商文件夹可能包含外部库使用的源代码控制系统的痕迹，这些可能会混淆您的项目源代码控制。正确的工作流程是提交composer.lock，并且每个签出您的项目的人都必须运行composer install以从互联网上获取这些依赖项。这也适用于执行检出的部署脚本。

于 2013-10-21T18:32:14.347 回答