我使用composer主要来管理git存储库（本地和远程）。Composer 读取所有历史提交中每个标记的 composer.json 实例：
Reading composer.json of tomekwi/composer-installers (v1.0.0)
Importing tag v1.0.0 (1.0.0.0)
Reading composer.json of tomekwi/composer-installers (v1.0.1)
Importing tag v1.0.1 (1.0.1.0)
Reading composer.json of tomekwi/composer-installers (v1.0.2)
Importing tag v1.0.2 (1.0.2.0)
Reading composer.json of tomekwi/composer-installers (v1.0.3)
Importing tag v1.0.3 (1.0.3.0)
Reading composer.json of tomekwi/composer-installers (v1.0.4)
Importing tag v1.0.4 (1.0.4.0)
Reading composer.json of tomekwi/composer-installers (v1.0.5)
Importing tag v1.0.5 (1.0.5.0)
Reading composer.json of tomekwi/composer-installers (v1.0.6)
Importing tag v1.0.6 (1.0.6.0)
Reading composer.json of tomekwi/composer-installers (1.x)
Importing branch 1.x (1.x-dev)
...etc
较大的存储库需要很长时间。此外，它还会导致 github （https://circleci.com/docs/composer-api-rate-limit） 出现问题
如果我理解正确，这样做的目的是从每个 composer.json 文件中提取版本号。如果作曲家只通过读取标签名称来选择正确的版本，那会快得多。请求"tomekwi/composer-installers": "~1.0"可能如下所示：
Reading tags of tomekwi/composer-installers
- Picked matching tag (v1.0.6)
Reading composer.json of tomekwi/composer-installers (v1.0.6)
- Installing tomekwi/composer-installers (v1.0.6)
..并且需要半秒钟而不是半分钟。
可以这样做吗？
Composer 不知道存储库中有什么包。所以它必须阅读composer.json才能找到答案。
而且由于软件可以重命名，因此无法保证在存储库中找到的每个标签都属于相同的包名称。
您应该查看托管Packagist或Satis的本地实例。这些工具会扫描您的存储库并获取 Composer 工作所需的信息。Satis 还可能将找到的标记转储到 ZIP 文件中，这也加快了安装过程（从本地服务器解压缩下载的文件通常比克隆存储库更快）。