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

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

问题描述:

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 ?

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

所以我这样做了,我的目录结构看起来像这样 : p>

  project 
 | ----- .git 
 | ----- libs 
 | ---- guzzle 
 | ----  .git 
 | ---- phpunit 
 | ---- .git 
  code>  pre> 
 
 

所以 guzzle code>和 phpunit code>文件夹都有一个单独的 .git code>文件夹。 这是因为,据我所知,作曲家从github克隆了主分支,以便检索这些库的源代码。 p>

所以我做了一个提交+推送 在远程存储库上。 但是,当其他人从该存储库中提取时, libs / guzzle code>和 libs / phunit code>文件夹中包含的文件不会出现在该人员的工作目录中。 p>

我认为这是因为2 .git code>文件夹。 p>

我该如何解决这个问题? 我试着在composer文件中搜索一下在 composer.json code>中指定的方法来获取最后一个快照。 但我找不到任何东西。 p>

我还考虑过删除 .git code>目录,但是如果我尝试做一个作曲家更新 code>? p>

过去有没有人遇到过这类问题? 你是怎么解决的? p> div>

I have some comments and explanations.

First, your usage of Composer created git clone artefacts. While this isn't completely bad, it should be avoided because cloning a repo of an active project usually is a lot more data than installing a released version.

Try to use --prefer-dist if you can. This will download ZIP files of the version, not clone from Github. Note that this option is the default for stable versions, which brings me to the next point...

Do use stable versions. Do not use dev-master versions if you can avoid it. You mentioned using PHPUnit and Guzzle. Both are released in stable versions that you can use. Do it. There is no benefit with these two libraries to use unstable development versions, unless you absolutely need a feature. The problem with using an unstable version might not be showing right away. But think about what would happen half a year from now. Somebody updates your dependencies pointing to dev-master, which now points to whatever happened since then. PHPUnit or Guzzle might have had a new major release with incompatible changes. And now your project breaks unnecessarily.

Another thing is the requirement to put external libraries in defined folders. It is doable, but it shouldn't really be done. Composer does work with any folder, but my usual reaction to seeing a composer.json in the top level directory is to expect getting a vendor folder containing the autoload.php. Changing this needs a little bit more of explanation to a new developer who might also expect Composer to work as default as possible. Because there is no reason to put Composer-managed dependencies anywhere, they are best put where everyone would expect them. Don't change the vendor folder if you don't have to.

And the last point is: Do commit your composer.lock, but don't commit the vendor folder. This is because the vendor folder might contain traces of the source control systems used by the external libraries, and these might confuse your projects source control. The correct workflow is to commit the composer.lock, and everybody checking out your project has to run composer install to grab these dependencies from the internet. This also applies to deployment scripts that do the checkout.

Apparently what I'm trying to do is a bad idea, as mentioned here. I will have to find another way of installing / using these libraries.